The toolchain_target_settings_test fails on Bazel 7.7.0 because the config.add_transition_setting + apply_config_settings_attr interaction relies on label string formatting that is inconsistent across Bazel versions.

Root cause:

Bazel 8.0 release notes state:

[Incompatible] All labels in Bazel error messages, log output, Build Event Protocol, etc. are now prefixed with double-at (@@) instead of single-at (@) where applicable, to properly denote that they contain canonical repo names.

The flow:

1. config.add_transition_setting(setting = "//:family") calls str(tag.setting) in config.bzl
2. That string lands in EXTRA_TRANSITION_SETTINGS -> TRANSITION_LABELS -> transition inputs/outputs
3. apply_config_settings_attr calls str(key) on the Label from config_settings = {"//:family": "custom"}
4. The transition output key from step 3 must exactly match the input key from step 2

On Bazel 7, str(Label(...)) produces single-@ labels (e.g. @//:family), but str(tag.setting) for attr.label in a module extension tag can produce a different form (e.g. @module_under_test//:family). This mismatch means the transition output key does not match any input key -> the family flag stays at its default ("prebuilt") -> the is_prebuilt config_setting matches -> the gated default toolchain resolves -> the build succeeds when it should fail.

Bazel 8 fixed this with the @@ canonicalization change, making label strings consistent across all APIs. This is tracked by the umbrella issue bazelbuild/bazel#11128 "Support workspace label prefixes in Starlark config and platform APIs", which encompassed related sub-issues (#9065, #10152, #10499, #10927).

Fix: Restrict toolchain_target_settings_test to bazel_versions = ["8.5.1", "9.1.0"] where cross-repo transition labels resolve consistently.

Sorry for the LLM analysis, but I was a little baffled why this started failing now. The rest has been crafted with Artisanal Intelligence.

at some point our deps will drop it and it will be difficult to support

Is there such a case today? Or a dependency we want to use, but it's bzlmod only so using it is tough. I would find that very compelling.

Because Bazel 8 supports workspace, and Bazel 8 is in support until Dec 2027, support for workspace is still technically around for another 1.5 years.

But yeah, the oldest bazel version supports bzlmod now. And AFAIK, Bazel 7 bzlmod is decent; decent enough one can use bzlmod with Bazel 7.

2.1 or 3.0

Eh, mild preference for 3.0 because we aren't being forced to drop support due to a dependency. I'm fine either way, though.

may need to wait until we discuss what we're doing with downstream users

I asked the protobuf people what plans they have. If they respond back, I'll post back.

If we agree that this is a 3.0 change, then let's look at the other things we should do for 3.0 and do it at once. I am OK with it being a 3.0 thing.

In talking with the protobuf people, they were somewhat alarmed that rules_jvm_external and the others mentioned in the slack thread had dropped workspace support already.

Protobuf said they plan to drop workspace Q1 2027, so basically just after Bazel 7 is out of support (but before bazel 8 is out of support).

they were somewhat alarmed that rules_jvm_external and the others mentioned

Let's see how it plays out. I don't want to drop WORKSPACE just to make our lives more painful and force users to not be able to update to 2.1 and above.

+1 to holding off until at least the protobuf team drops WORKSPACE support, if not until Bazel 8 is out of support. Even though I'd love to have it gone, haha.

+1 to dropping WORKSPACE being a 3.0 change.