bzlmod sneaks into a non-bzlmod build: very frequent recomputation of main repo mapping

[otiv-milan]

Hi, I recently started using Rust and rules_rust. At the moment I am at Bazel 7.1.1 and rules_rust 0.42.1. My workspace setup looks very similar to:

load("@rules_rust//rust:repositories.bzl", "rules_rust_dependencies", "rust_register_toolchains")

rules_rust_dependencies()

RUST_VERSION = "1.77.2"
rust_register_toolchains(
    versions = [RUST_VERSION],
)

load("@rules_rust//crate_universe:repositories.bzl", "crate_universe_dependencies")

crate_universe_dependencies()

load("@rules_rust//crate_universe:defs.bzl", "crate", "crates_repository", "render_config")

crates_repository(
    name = "crate_index",
    rust_version = RUST_VERSION,
    cargo_lockfile = "//:Cargo.lock",
    lockfile = "//:Cargo.Bazel.lock",
    packages = {
        "foo": crate.spec(
            version = "0.3",
        ),
        # ...
    },
    # Setting the default package name to `""` forces the use of the macros defined in this repository
    # to always use the root package when looking for dependencies or aliases. This should be considered
    # optional as the repository also exposes alises for easy access to all dependencies.
    render_config = render_config(
        default_package_name = "",
    ),
)

load("@crate_index//:defs.bzl", crate_repositories = "crate_repositories")

crate_repositories()

This setup works, I can compile stuff, that's not a problem. However, I very often get that Bazel wants to fetch crate index, rust, llvm repos:

Computing main repo mapping: 
    Fetching repository @@crate_index; starting 6s
    Fetching repository @@rust_linux_x86_64__x86_64-unknown-linux-gnu__stable_tools; starting 6s
ERROR: command interrupted while computing main repo mapping
Computing main repo mapping: 
    Fetching repository @@crate_index; starting 8s
    Fetching repository @@rust_linux_x86_64__x86_64-unknown-linux-gnu__stable_tools; starting 8s
    Fetching ...f32f073497a6ccc9cda6de6ad6bb9c0/external/rust_linux_x86_64__x86_64-unknown-linux-gnu__stable_tools; Extracting llvm-tools-1.77.2-x86_64-unknown-linux-gnu.tar.xz

Like, I edit a build or .bzl file, I get this. Almost always.

Also, I often get the messages like:

Another command (pid=159000) is running. Waiting for it to complete on the server (server_pid=763)...

when running Bazel in one shell.

I've been working with Bazel for a while and I observe this behavior only since I started using rules_rust.

Am I missing something obvious?

[otiv-milan]

BTW, my .bazelrc looks like https://github.com/mvukov/rules_ros2/blob/main/.bazelrc.

[mvukov]

OK, looks like the culprit is --noenable_bzlmod in my .bazelrc. I created a simple workspace where I only import rules_rust. If my .bazelrc has --noenable_bzlmod then it's enough to just edit a build file (add a comment) to have a msg for computation of main repo mapping visible for at least 0.5 seconds.

[otiv-milan]

My current understanding is that Bazel msg such as Computing main repo mapping only happens when bzlmod is enabled. I am puzzled why it happens in my case where I explicitly disable bzlmod. @illicitonion WDYT?

[otiv-milan]

This also happens with the current rules_rust 0.45.1 and Bazel 7.1.2.

[UebelAndre]

Is this unique to rules_rust? Feels like a Bazel issue

[otiv-milan]

I've never experienced this behavior/issues from Bazel before I started working with rules_rust. Have you experienced something similar? Or you already switched to bzlmod?

[illicitonion]

My current understanding is that Bazel msg such as Computing main repo mapping only happens when bzlmod is enabled. I am puzzled why it happens in my case where I explicitly disable bzlmod.

I believe "Computing main repo mapping" is output in Bazel 7 with or without bzlmod.

I agree that this sounds like a general Bazel issue, though if there's some API rules_rust is using wrong which triggers it we'd be interested in fixing it!

[otiv-milan]

OK, thanks for the info. I also figured out in the meantime that Bazel 7.x always computes repo mappings. I think this issue is really about bzlmod vs nobzlmod in rules_rust. I created a minimal example in a new issue #2672.