Use launcher wrapper to initialize runfiles

[mering]

This avoid the need to copy&paste the verbose initialization snippet into every script.

This should resolve the issues raised in #24.

[fmeum]

I really like the ergonomics of this approach. It also cleanly avoids the issues #24 had.

Since sh_binary is such a foundational rule and has always had a simple shell script with no "deps" as its executable, I'm worried that we could be breaking users by introducing a launcher of sorts. In particular since it probably requires bash.

What do you think of gating the new behavior behind a boolean attribute for now? We could also consider making this an attribute of sh_toolchain instead, which would only require opt-in in a single location.

Could you also add an example to the BCR test module to exercise this new functionality?

[mering]

Since sh_binary is such a foundational rule and has always had a simple shell script with no "deps" as its executable, I'm worried that we could be breaking users by introducing a launcher of sorts. In particular since it probably requires bash.

IIUC the runfiles library itself requires bash, so if we want to provide runfiles functionality, then I think there is no way around it. Instead of hardcoding /bin/bash, can I get the absolute path for the interpreter from the toolchain somehow?

What do you think of gating the new behavior behind a boolean attribute for now? We could also consider making this an attribute of sh_toolchain instead, which would only require opt-in in a single location.

Sure, sounds like a good approach to have a knob for people in case there are incompatibilities. Do you have a suggestion on how to name this attribute?

Could you also add an example to the BCR test module to exercise this new functionality?

I tried it with the existing examples and it works like a charm for Bazel 8 but IIUC with Bazel 6 and 7 it uses the native rules instead of the ones in this repo. Is there a way to disable a test for Bazel 6 and 7?

[fmeum]

IIUC the runfiles library itself requires bash, so if we want to provide runfiles functionality, then I think there is no way around it. Instead of hardcoding /bin/bash, can I get the absolute path for the interpreter from the toolchain somehow?

Yes, but you always had the option to not use bash in your sh_binary, even if that meant you couldn't use the runfiles library.

You can get the path from https://github.com/bazelbuild/rules_shell/blob/e6d845428779b1e5ebb9971451ed3c43c865fc0b/shell/toolchains/sh_toolchain.bzl#L31. The Windows launcher part already uses this.

Sure, sounds like a good approach to have a knob for people in case there are incompatibilities. Do you have a suggestion on how to name this attribute?

How about use_bash_launcher? It should probably contain bash since that's what we force onto the user. It should also be more generic than, say, inejct_rlocation since I could see this being an avenue towards a more hermetic interpreter/tool setup.

I tried it with the existing examples and it works like a charm for Bazel 8 but IIUC with Bazel 6 and 7 it uses the native rules instead of the ones in this repo. Is there a way to disable a test for Bazel 6 and 7?

You could export a constant from a .bzl file that checks for hasattr(native, "sh_binary") and tag the test as manual depending on that constant. Feature detection is better than version detection.

[mering]

@fmeum I addressed all review comments.