Bzlmod lock file breaks cross-platform builds
If you build on one platform, it causes the bazel lock file to contain host-specific repositories, e.g.
"rust_host_tools": {
"bzlFile": "@@rules_rust~0.38.0//rust:repositories.bzl",
"ruleClassName": "rust_toolchain_tools_repository",
"attributes": {
"name": "rules_rust~0.38.0~rust~rust_host_tools",
"exec_triple": "x86_64-unknown-linux-gnu",
"target_triple": "x86_64-unknown-linux-gnu",
"allocator_library": "@rules_rust//ffi/cc/allocator_library",
"dev_components": false,
"edition": "2021",
"rustfmt_version": "nightly/2023-12-28",
"sha256s": {},
"urls": [
"https://static.rust-lang.org/dist/{}.tar.xz"
],
"version": "1.75.0"
}
},
Building on a different platform than the one that generated the lock file causes the repository to be instantiated with these attributes, since instead of re-running the module extension it uses the cached attributes in the lock file. According to https://github.com/bazelbuild/bazel/issues/19154, the correct way of solving this is to remove host introspection in the module extension, and instead instantiate repositories for all host platforms, and use platform resolution to select the one to use.
I guess we can't use toolchain resolution during the loading phase, where we need the host tools. It looks like module_extension has some parameters that we can use to say a module extension is os or arch specific.
I think this needs splitting out into its own module extension, so that all the other toolchains don't become arch and os specific, and can be reused across platforms.
This has the side-effect of not being able to use the specified toolchain (edition, version, etc) as the host tools. However, I guess its fine to use a fixed version for these.
Im running into this as well