Unexpected interaction between toolchain resolution and bzlmod

[lberki]

Description of the bug:

When bzlmod is enabled (as it is the case in Bazel 7.0.0), toolchain registered by default can unexpectedly shadow toolchains declared in the WORKSPACE file. This makes the oucome of toolchain resolution dependent on whether bzlmod is enabled, even if the MODULE.bazel file of the main repository is empty (as it is by default)

The root cause seems to be different from #17289 : there, AFAIU that one is caused by a subtle interaction between label mapping and toolchain resolution, here it's much more straightforward.

Some debugging indicates that what happens is that RegisteredToolchainsFunction creates the list of registered toolchains by concatenating two lists: those from bzlmod, then those from the WORKSPACE file. rules_python is by default and immutably (except if bzlmod is disabled) a bzlmod module and it registers @bazel_tools//tools/python:_autodetecting_py_runtime_pair as a Python toolchain. Since that toolchain doesn't have any exec or target constraints, it seems to win toolchain selection by default, regardless of what other toolchains come after.

Therefore, no matter what is written in the WORKSPACE file, one gets the autodetecting Python toolchain.

I'm not sure if this is WAI; it could be construed as such, but it sure is surprising and a hindrance to migration to bzlmod.

Which category does this issue belong to?

No response

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

cat > WORKSPACE <<'EOF'
register_toolchains("//tc:py_toolchain")
EOF

cat > BUILD <<'EOF'
py_binary(
    name = "py",
    srcs = ["py.py"],
)
EOF

cat > py.py <<'EOF'
print("Hello, Python!")
EOF

mkdir tc

cat > tc/BUILD <<'EOF'
load("@bazel_tools//tools/python:toolchain.bzl", "py_runtime_pair")

py_runtime(
    name = "python2",
    files = ["ok.py2"],
    interpreter = "ok.py2",
    python_version = "PY2",
)

py_runtime(
    name = "python3",
    files = ["ok.py3"],
    interpreter = "ok.py3",
    python_version = "PY3",
)

py_runtime_pair(
    name = "pair",
    py2_runtime = ":python2",
    py3_runtime = ":python3",
)

toolchain(
    name = "py_toolchain",
    toolchain = ":pair",
    toolchain_type = "@bazel_tools//tools/python:toolchain_type",
)
EOF

bazel run --enable_bzlmod :py  # BUG: Prints "Hello, Python!", ignoring the toolchain
bazel run --noenable_bzlmod :py  # WORKS: Fails to find the dummy interpreter defined above

Which operating system are you running Bazel on?

Linux

What is the output of bazel info release?

development version

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

From sources

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

4a29f0851d1cde0240793cdc7a2e2cab926d31b7

Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

Pretty obviously when --enable_bzlmod was flipped to true.

Have you found anything relevant by searching the web?

There are a number of pertinent bugs:

• --enable_bzlmod breaks toolchain resolution for toolchains registered in WORKSPACE #17289 (but that has a different root cause, if I understand correctly)
• Using bzlmod (at all) breaks Python interpreter version specifications rules_python#1313 (seems to be very similar, but I haven't seen evidence that the bzlmod folks looked at this and has less information as to why this happens)

Any other information, logs, or outputs that you want to share?

No response

[meisterT]

cc @meteorcloudy

[fmeum]

One possible solution I see is to change the order of registration to the following in order of decreasing precedence:

1. Toolchains registered in the root module's MODULE.bazel file
2. Toolchains registered in the WORKSPACE file
3. Toolchains registered in dependencies' MODULE.bazel files in BFS order

Independent of that particular issue, the auto-detecting Python toolchain should have constraints to match on the auto-detected host platform, otherwise it probably breaks remote execution of Python tools.

[meteorcloudy]

RegisteredToolchainsFunction creates the list of registered toolchains by concatenating two lists: those from bzlmod, then those from the WORKSPACE file.

Yes, this is WAI. But we probably should document the priorities of toolchain registration more clearly.

Toolchains registered in the root module's MODULE.bazel file
Toolchains registered in the WORKSPACE file
Toolchains registered in dependencies' MODULE.bazel files in BFS order

This does look like a better order since it gives more control to users. But still could be surprising and should be documented.

Independent of that particular issue, the auto-detecting Python toolchain should have constraints to match on the auto-detected host platform, otherwise it probably breaks remote execution of Python tools.

/cc @rickeylev

[lberki]

Yep, I find the order proposed by @fmeum more intuitive than what's at HEAD.

[fmeum]

There is a potential problem with this new order though: We can't distinguish top-level toolchain registrations from those coming from WORKSPACE macros or even the suffix. This could result in unexpected results of a different kind.

[katre]

Ideally toolchains registered in the workplace suffix would have the lowest priority (that's what effectively happened before bzlmod was a thing).

We've discussed (and I can't currently find the issue) adding explicit priority levels to register_toolchains: that could be used with some defaults to set the order of toolchains as described, but I'd want to take some time and flesh out the problem.

Fixing the python toolchains should be very easy, if @rickeylev wants help I can provide pointers.

What's the priority on fixing bzlmod/workspace toolchain ordering?

[lberki]

If you told me the behavior at HEAD is by design, I'd grudgingly accept that and ask how we could help people like the Kleaf folks with their migration. They do have a point that this (and other behavior similarly surprising, if it exists) doesn't make migration to bzlmod easy. I have a number of ideas which could make this more intuitive, but given that I you and @Wyverald follow toolchains and bzlmod much closer than I do, I'd rather not voice them before being asked.

Practically speaking, I don't think there is a rush, at least from this project, given that they also need bzlmod vendoring to be able to turn bzlmod on. But let's not fall into the trap where both issues get deferred because they expect the other one to progress slowly :)

[katre]

Went ahead and wrote up #20356 for the python part: @lberki, while tests are running, can you see if this addresses the original issue?

[lberki]

It doesn't fix the repro in the description of this bug, so I guess it does not?

[katre]

That's unfortunate. Can you share the repro with me?

[lberki]

It's in the description of #20354 , complete with a shell snippet to produce a repository from scratch and example Bazel invocations.

[katre]

Whoops, sorry

[Wyverald]

Is it feasible for Kleaf to move/copy their toolchain registrations from WORKSPACE to MODULE.bazel? That would be the immediate fix.

[katre]

Using --extra_toolchains in a bazelrc would also be a workaround.

[rickeylev]

rules_python is by default and immutably (except if bzlmod is disabled) a bzlmod module and it registers @bazel_tools//tools/python:_autodetecting_py_runtime_pair as a Python toolchain.

Well, yes and no. There's three different mechanisms that can cause it to get registered when you don't expect it:

1. As part of Bazel itself. I don't know where this puts it in the toolchain priorities, but it happens very early, when Bazel is initializing the rule types it knows about. See

   bazel/src/main/java/com/google/devtools/build/lib/bazel/rules/BazelRuleClassProvider.java

   Line 479 in 38e8da1

   ResourceFileLoader.loadResource(BazelPyBinaryRule.class, "python.WORKSPACE"));

   and

   bazel/src/main/java/com/google/devtools/build/lib/bazel/rules/python/python.WORKSPACE

   Line 4 in 38e8da1

   # line or WORKSPACE file. (And even if we did register it here, we still

2. As part of older rules_python "releases" (0.4 to 0.12). I put releases in quotes because, from what I can tell, those releases are of rules_python versions that didn't actually have bzlmod support. I'm guessing they were manually created to help bootstrap things. After that, the autodetecting toolchain is no longer registered. Starting in 0.23.0, a hermetic toolchain is automatically registered. Also note that Bazel itself depends on rules_python 0.4.0 right now (I have a pending change to upgrade that to 0.22.0, which doesn't register the autodetecting toolchain). See https://github.com/search?q=repo%3Abazelbuild%2Fbazel-central-registry+path%3Amodules%2Frules_python+autodetecting_toolchain&type=code
3. The rules_bazel_integration_test module registers the autodetecting toolchain. So if that's in the module graph, that'll happen. See https://github.com/search?q=repo%3Abazelbuild%2Fbazel-central-registry+-path%3Amodules%2Frules_python+autodetecting_toolchain&type=code

bazelbuild/rules_python#1313

That actually sounds exactly like this issue: the user has an empty module, a workspace registering a toolchain, but then when they enable bzlmod, their toolchain is ignored.

As an aside, don't use the stuff in @bazel_tools//tools/python. Use @rules_python instead.

[Wyverald]

There is a potential problem with this new order though: We can't distinguish top-level toolchain registrations from those coming from WORKSPACE macros or even the suffix. This could result in unexpected results of a different kind.

This is a fixable problem, actually. We could annotate toolchains registered in WORKSPACE suffixes with a "low priority" bit (messy, but technically possible), then order the toolchains per 1) root MODULE.bazel 2) WORKSPACE sans suffix 3) non-root Bzlmod stuff 4) WORKSPACE suffix. This would address the Kleaf use case.

[fmeum]

I believe that this is catching more users by surprise: https://bazelbuild.slack.com/archives/CA306CEV6/p1701394561232659

It's pretty hard to come up with why this is failing if users are not aware of MODULE.bazel at all, as in this case.

[meteorcloudy]

@bazel-io fork 7.0.0

[meteorcloudy]

Since Bzlmod is enabled by default in Bazel 7 and that could trigger this issue for many users, we should probably address this in 7.0.0.

[iancha1992]

A fix for this issue has been included in Bazel 7.0.0 RC6. Please test out the release candidate and report any issues as soon as possible. Thanks!