Support for executing WASM modules in repository_ctx

[jmillikin]

I originally filed this as an issue at #22483, but it might be better as a discussion until some rough consensus can be reached.

The basic problem I want to address is the use of complex language-specific BUILD file generators in rulesets. Currently these tools need to execute on the host, which means a native binary for the host platform must either (1) exist as a pre-compiled download, or (2) be built as part of repository rule execution. Both approaches have significant drawbacks:

• Pre-compiled downloads for ruleset tools only exist for the most popular platforms. For example the rules_rust ruleset provides the cargo-bazel tool compiled for Linux, macOS, and Windows on x86-64 and aarch64 -- while this does cover most users, it means that I can't easily test the Bazel builds for my Rust projects on FreeBSD or RISC-V.
  • The set of host platforms supported by Bazel is large. It would be unreasonable to expect ruleset authors to provide pre-compiled binaries for every platform that Bazel can be coaxed into run on.
  • Logic within a repository rule to discover the host platform is fussy and fragile, and usually fails to distinguish platform variants (such as -gnu vs -musl on Linux).
• Compiling the tool just-in-time as part of the repository rule is slow, runs without sandboxing, and is un-cacheable. Lack of sandboxing can cause hermeticity errors, such as builds that depend on dotfiles in the user's homedir, or accidental mutation of lock files in the source tree.
  • At a previous employer, modifying rules_go to use precompiled gazelle binaries provided a significant improvement in CI performance but made the process of updating rules_go much more difficult.

Over the past few years, support for WASM as both a compilation target and embedded interpreter has become widespread. Many languages (including Rust and Go) can be compiled to standalone WASM binaries, and the Chicory runtime implements a WASM interpreter in Java with no native code dependencies.

If it were possible to execute a WASM binary within a repository rule, then ruleset authors could provide a single pre-compiled .wasm file and Bazel could execute it on every platform with identical behavior and full sandboxing. The API does not need to be complex -- since Bazel can handle the file I/O using existing repository_ctx functions, the WASM blob only needs to provide pure functions and the API can be written in terms of plain byte buffers.

I've put together a proof-of-concept to verify that this does in fact work as expected, using WASM modules written in Rust and Go (modified from existing ruleset tools). The resulting repository rules work without modification on all the host platforms I have tried, and they no longer need to execute uname or poke around in /lib to detect host properties.

[sluongng]

ruleset authors could provide a single pre-compiled .wasm file and Bazel could execute it on every platform with identical behavior and full sandboxing

I don't see a strong motivation here.

Rules author would then have to worry about (a) producing a wasm artifact and (b) store/distribute that wasm artifact vs just writing the current starlark rules and leveraging Github/BCR archive ecosystem.

The sandboxing argument is also not that appealing to me either.
For most cases that require a strong sandbox to improve hermeticity, rules set authors would/should use build rules to create them. Repository rules are non-hermetic by nature. It has access to rctx.os which folks often leverage to setup platform-specific logic (i.e. downloading platform-specific deps).

What problem would "having a hermetic sandbox for rctx" solve?
If there is a concrete problem, we can consider extending the current API to enable remote execution for rctx as an alternative solution.
The basic wiring for RBE for repository rules' actions has already been in place for a while now, but was never used by the popular rule sets.

[jmillikin]

Rules author would then have to worry about (a) producing a wasm artifact and (b) store/distribute that wasm artifact vs just writing the current starlark rules and leveraging Github/BCR archive ecosystem.

Rules authors currently must worry about producing native binary artifacts for various combinations of architecture and OS, for example bazelbuild/rules_rust v0.54.1 has 8 pre-built cargo-bazel binaries:

• cargo-bazel-aarch64-apple-darwin
• cargo-bazel-aarch64-pc-windows-msvc.exe
• cargo-bazel-aarch64-unknown-linux-gnu
• cargo-bazel-x86_64-apple-darwin
• cargo-bazel-x86_64-pc-windows-gnu.exe
• cargo-bazel-x86_64-pc-windows-msvc.exe
• cargo-bazel-x86_64-unknown-linux-gnu
• cargo-bazel-x86_64-unknown-linux-musl

It's unreasonable to expect rules authors to build binaries for every platform Bazel supports, but not doing so locks out users of less-common platforms (such as Linux on RISC-V, or *BSD).

Producing a single .wasm artifact is easier and more portable.

The sandboxing argument is also not that appealing to me either. For most cases that require a strong sandbox to improve hermeticity, rules set authors would/should use build rules to create them.

The outputs of build rules can't be used as inputs to a repository rule.

Repository rules are non-hermetic by nature. It has access to rctx.os which folks often leverage to setup platform-specific logic (i.e. downloading platform-specific deps).

That's not what repository_ctx.os is for, because that variable identifies the platform that Bazel is running on. It doesn't identify the execution or target platforms. Downloading platform-specific dependencies is handled via platform-specific repository rules, registered as toolchains.

What problem would "having a hermetic sandbox for rctx" solve? If there is a concrete problem, we can consider extending the current API to enable remote execution for rctx as an alternative solution. The basic wiring for RBE for repository rules' actions has already been in place for a while now, but was never used by the popular rule sets.

I don't understand how remote execution has any connection to this feature request.