Making genrules work with the hermetic sandbox by making genrules take a launcher/default dependencies

[sin-ack]

Summary

It should be possible to, in some way, add dependencies that are currently expected to be implicitly present to genrules (for example, the shell or coreutils). This will allow third-party genrules to work properly when --experimental_use_hermetic_linux_sandbox is enabled.

Background

We are currently trying to increase the reproducibility of our build system at my company, and in general the reproducibility of Bazel as a whole. Currently, Bazel has a few defaults that result in diminished hermeticity OOTB:

• The most important toolchain, cc_toolchain, is automatically configured from the user's system.
• Certain things like ctx.actions.run_shell and genrule simply assume that a shell such as Bash, and various tools such as GNU coreutils exist in the file system view.
• Additionally, it's not possible to tell them to use a target for the shell; --shell_executable (used for ctx.action.run_shell and genrule) and sh_toolchain (used for sh_* targets) both take an absolute path parameter, which cannot carry dependencies into the sandbox closure.

We are fixing some of our issues on our side using Nix for toolchains and final artifacts. To ensure that hermeticity is actually accomplished, we use --experimental_use_hermetic_linux_sandbox which eliminates any implicit filesystem dependencies that can happen. However, some things like genrule are currently not possible to make hermetic automatically. Further, while we could manually add a custom toolchain which would make them available, this doesn't work for third-party packages on the BCR, for example.

Therefore, there should be a way to either pass a launcher to these rules that works in Unix, or a way to add default inputs to genrule such that they're included by default.

Suggested Approach

Assuming the launcher approach is taken:

• First off, sh_toolchain should make launcher used in all platforms, if available (perhaps this could be introduced in a backwards-compatible way like unix_launcher).
• This launcher should be exposed to genrule by:
  • Introducing something like the current Java-native CcToolchainInfo, introducing a toolchain type that Java can recognize, and make sh_toolchain emit this provider. (This is definitely not my favorite approach because it adds more stuff to the Java side.)
  • Moving genrule to be completely Starlark-based, making anything Java-only that it needs available to Starlark as well (I looked through GenRuleBase and nothing jumped out as being impossible to do in Starlark, except perhaps observing --stamp which there is an open issue for: Allow Starlark rules to observe the --stamp setting #11164), and then depending on the shell toolchain in the rule definition.
    • Note that this doesn't address how ctx.action.run_shell would work. In my mind it's kind of a misfeature anyhow.
• Finally, genrule should use the launcher instead of the hardcoded default shell for running the code. This launcher would then adjust the PATH to make available a set of binaries that genrules are likely to want before exec'ing into the shell.

I'm aware that making stuff like the shell completely hermetic by default is likely out-of-scope for Bazel; therefore, doing this would give the leeway for projects to set it up themselves.

Workarounds

There is currently a workaround to this in the form of the obscure bazel_prelude functionality, which would allow us to override genrule with a rule that does ctx.actions.run on the hermetic launcher.

[fmeum]

I support this direction and also believe that run_shell should be a function or subrule in rules_shell - it shouldn't live in Bazel core.

Starlarkifying genrule would be great, but there are likely more native-only features (e.g. the toolchains attribute supporting toolchain types) that may make this difficult.

A related proposal that I unfortunately haven't found the time to fully think through: https://github.com/bazelbuild/proposals/blob/main/designs/2025-06-18-sh-toolchain-for-run-shell.md