MODULE.bazel.lock contains os-specific information

[kyleconroy]

We're using Bazel 7.4.1, bzlmod, and rules_rust 0.57.0.

I'm currently running into an issues where the MODULE.bazel.lock file is different for macOS and Linux. Our development team is split across operating systems. We commit the lock file into git. After doing a build, this is the output.

% git diff
diff --git a/MODULE.bazel.lock b/MODULE.bazel.lock
index e469d34c..5a4e577b 100644
--- a/MODULE.bazel.lock
+++ b/MODULE.bazel.lock
@@ -2450,13 +2450,13 @@
         "bzlTransitiveDigest": "EdXtlrLdE7Da59jNE81dWF8Gtmkk/k+t7HQipinlkys=",
         "usagesDigest": "s984p4lEI8oILLOAsSJoxCw9XxONrc+GZDviDKss1zo=",
         "recordedFileInputs": {
-          "@@rules_rust~~rust_host_tools~rust_host_tools//bin/rustc": "241027b94ad67beb36d0356f7cc05180daaa9966b2958cfba1d4de089d2e521c",
+          "@@rules_rust~~rust_host_tools~rust_host_tools//bin/rustc": "b953c69e6f682bf55e39bdd55bdcbd3e1cc0cbdf9dfda24b9c6478ee2c38359b",
           "@@//tools/protoc-gen-rust/Cargo.lock": "8fa0f54c3148432f7fc8f9ca965a99a8d68b63e287b70b988fc4c8bc80ef20e3",
           "@@//code/Cargo.toml": "7f74cfc4b2e5cb5498ea299be71ae53ad45b2fc3dd81b90e3360fe2004c70b19",
           "@@//tools/protoc-gen-rust/Cargo.toml": "43ce3024fafb7937c5cdf5b3ff5da955cc3ba949b4e3461a2d4108903244f57e",
           "@@//code/Cargo.lock": "83cbfba676ff03848c866bfe55bee28e4ea4cdd254a4791c5ba20a47f26515fa",
-          "@@//MODULE.bazel": "0ea6c3b67b68921e1650b9d0332b7a3bf1490e2d1f4c3d7e0233565283f9aabc",
-          "@@rules_rust~~rust_host_tools~rust_host_tools//bin/cargo": "35099f3b7b9497b3ae95aa00886ac6839343488e5cdb958e69c16c9b58c3afb2"
+          "@@//MODULE.bazel": "21b7f26f2e1130e2f2b145b234ca20a877df056063c2e94acef247dccb1ce3db",
+          "@@rules_rust~~rust_host_tools~rust_host_tools//bin/cargo": "be459aeefa634aa6693a9a4741cfa4d63dd8a50af2d1a8ff221b7565e7eb4e4c"
         },
         "recordedDirentsInputs": {},
         "envVariables": {

The previous values for rustc are for Linux, the new ones are for macOS.

Our MODULE.bazel contains the following rust configuration

rust = use_extension("@rules_rust//rust:extensions.bzl", "rust")
rust.toolchain(
    edition = "2021",
    versions = ["1.83.0"],
)
use_repo(rust, "rust_toolchains")
register_toolchains("@rust_toolchains//:all")

# Option 1: Fully transient (Cargo.toml / Cargo.lock as source of truth).
crate = use_extension(
    "@rules_rust//crate_universe:extension.bzl",
    "crate",
)

crate.from_cargo(
    name = "crates",
    cargo_lockfile = "//code:Cargo.lock",
    manifests = ["//code:Cargo.toml"],
)

use_repo(crate, "crates", "crates_protoc")

[kyleconroy]

I discussed this with a few other people on Slack. They confirmed this is currently an issue.

[UebelAndre]

in order to do splicing, crate_universe needs access to a rustc binary and cargo binary that will run on the host. I'm a newb to bzlmod so don't know what a good way to describe this is. I filed #3286 for what I think is a closely related issue.

[aignas]

Just randomly stumbled upon this, not intending to send PRs but just providing context how a similar issue got solved in rules_python.

I needed to go through hoops to ensure that we have no host python references like here: bazelbuild/rules_python#2135

The main gist is:

• Pass the label of the host tool to the extension.
• When invoking the tool, first get the directory path by getting path to BUILD.bazel file next to where the binary of the tool lives.
• Call module_ctx.path(watch = false) when getting the actual path to the binary. This way the entries in the lock file are pointing to the BUILD.bazel file that are platform independent (hopefully).

Here is the snippet I am trying to outline above: https://github.com/bazelbuild/rules_python/pull/2135/files#r1972759635

[UebelAndre]

• Call module_ctx.path(watch = false) when getting the actual path to the binary. This way the entries in the lock file are pointing to the BUILD.bazel file that are platform independent (hopefully).

That doesn't seem to be a documented feature: https://bazel.build/rules/lib/builtins/module_ctx#path

Is that real? lol

[aignas]

Oh sorry, I misremembered. :D I think the repository_ctx may have that arg. Maybe I was talking to fmeum about this. Anyway, the snippet I linked might be sufficient.