jmillikin
commented
5 days ago I've built a proof-of-concept for this feature using Chicory, a WASM runtime written in Java. It isn't large (maybe ~500 LoC excluding tests), and it's able to run modules written in Go (via TinyGo) and Rust. Chicory itself is small (~161 kB) and has no additional dependencies.
Would the Bazel devs be interested in reviewing an implementation PR?
Demo repository rule:
def _wasm_demo(ctx):
# Would be obtained from ctx.download_and_extract() normally
ctx.file("example/src.go", "package main\n")
# Inputs are assembled by Bazel, using path.readdir() / ctx.read(), etc
srcs = {"example/src.go": ctx.read("example/src.go")}
result = ctx.execute_wasm(
path = ctx.attr._demo_wasm,
function = "wasm_repo_demo",
input = json.encode({"srcs": srcs}),
)
# Output contains instructions to the rule as to which changes
# to apply, for example writing/patching BUILD files.
output = json.decode(result.output)
print("output: %s" % (repr(output),))
ctx.file("BUILD.bazel", "")
ctx.file("WORKSPACE.bazel", "")
wasm_demo = repository_rule(
_wasm_demo,
attrs = {
"_demo_wasm": attr.label(
default = "@//:demo.wasm",
allow_single_file = True,
)
}
)
fmeum
Description of the feature request:
I would like to be able to execute a WASM module from a
repository_ruleimplementation function, as an alternative to native binaries.The API would look something like this:
The repository rule implementation function is responsible for assembling an
inputstring and parsing theoutputstring according to its own needs -- for example, it might use JSON + thejsonmodule for structured input/output. The WASM module itself has no access torepository_ctxfunctionality.From the WASM side, the API looks like this:
Which category does this issue belong to?
External Dependency
What underlying problem are you trying to solve with this feature?
Generating
BUILDand.bzlfiles within a repository rule improves the user experience when adapting third-party code to build with Bazel. When the generation logic is too complex to write in Starlark, rulesets often rely on a helper binary for language-specific logic (e.g. enumerating imports).Embedding a WASM interpreter into Bazel and letting it execute WASM modules as part of repository rules can enable a different approach, where pre-compiled
.wasmmodules ship with the rules and can be executed on any platform that can run Bazel itself.Keeping the API very small (string input, string output) keeps the maintenance burden on Bazel itself to a minimum, with no need to worry about things like WASI or how to do WASM <-> JVM FFI.
Which operating system are you running Bazel on?
Linux (x86-64), macOS (aarch64)
What is the output of
bazel info release?release 7.1.1
If
bazel info releasereturnsdevelopment versionor(@non-git), tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse HEAD?No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response