-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
--enable_bzlmod breaks toolchain resolution for toolchains registered in WORKSPACE #17289
Comments
This feels to be Working As Intended, since modules specifically have a different way to register toolchains, but I'll leave it for @Wyverald to clarify. |
I passed this by @Wyverald on Bazel Slack and he asked to create an issue and cc him. Was just trying to find his GitHub handle :) If WORKSPACE files can't register toolchains when bzlmod is enabled then it will be hard to use rulesets that have bzlmod support alongside rulesets that don't (while they all get up to speed) if they both register toolchains. |
It's a bit early for this. `--enable_bzlmod` is not on by default in Bazel 6 and bzlmod still has many bugs such as bazelbuild/bazel#17289. We could add it back in a follow-up as an opt-in via a `aspect init --bzlmod` flag or via part of the wizard. We could also stamp out bzlmod and WORKSPACE boilerplate for rule sets as opt-ins via flags or wizards similar to how other tools create wizards work. GitOrigin-RevId: 2b7157d08d4acf2f7b72ac227c776257b9ae9137
It's a bit early for this. `--enable_bzlmod` is not on by default in Bazel 6 and bzlmod still has many bugs such as bazelbuild/bazel#17289. We could add it back in a follow-up as an opt-in via a `aspect init --bzlmod` flag or via part of the wizard. We could also stamp out bzlmod and WORKSPACE boilerplate for rule sets as opt-ins via flags or wizards similar to how other tools create wizards work. GitOrigin-RevId: 2b7157d08d4acf2f7b72ac227c776257b9ae9137
Only viable once all dependencies support it, see: bazelbuild/bazel#17289
Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 30 days. It will be closed in the next 7 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". |
Not stale. |
Ah, I think I figured out what's wrong here. It's that damn When you don't enable Bzlmod, When you enable Bzlmod, The immediate workaround would be to add a single line in your MODULE.bazel file ( |
Closing this as things are technically working as intended here. Hopefully the existence of this issue will serve as documentation for whoever's encountering this problem in the future. |
Uhm, the module system not resolving a dependency, and the user having to manually depend on a specific version of a deep dependency is "working as intended"? In my view this completely invalidates bzlmod. It might be working "as designed", but definitely not "as intended". |
Agreed, letting the user add a dependency to make it work isn't really a solution to me.
|
if anyone has an idea how to fix this, please leave a suggestion. |
Maybe making |
The canonical repo name of the `platforms` module is now forced to be `platforms`, which ensures that `@platforms` constraints used by toolchains defined in `WORKSPACE` match those referenced by the auto-configured host platform provided by `local_config_platform`. Fixes bazelbuild#17289 Closes bazelbuild#18624. PiperOrigin-RevId: 539710874 Change-Id: I171f308b06e7ec7559641b49b4c8c53dddac0d3c
The canonical repo name of the `platforms` module is now forced to be `platforms`, which ensures that `@platforms` constraints used by toolchains defined in `WORKSPACE` match those referenced by the auto-configured host platform provided by `local_config_platform`. Fixes #17289 Closes #18624. PiperOrigin-RevId: 539710874 Change-Id: I171f308b06e7ec7559641b49b4c8c53dddac0d3c Co-authored-by: Fabian Meumertzheim <[email protected]>
The canonical repo name of the `platforms` module is now forced to be `platforms`, which ensures that `@platforms` constraints used by toolchains defined in `WORKSPACE` match those referenced by the auto-configured host platform provided by `local_config_platform`. Fixes bazelbuild#17289 Closes bazelbuild#18624. PiperOrigin-RevId: 539710874 Change-Id: I171f308b06e7ec7559641b49b4c8c53dddac0d3c
Description of the bug:
Setting the
--enable_bzlmod
flag (even with an emptyMODULE.bazel
file) breaks toolchain resolution for toolchains registered in the WORKSPACE file.What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
https://github.com/gregmagolan/repro-enable_bzlmod_breaks_workspace
Which operating system are you running Bazel on?
MacOS
What is the output of
bazel info release
?If
bazel info release
returnsdevelopment version
or(@non-git)
, tell us how you built Bazel.What's the output of
git remote get-url origin; git rev-parse master; git rev-parse HEAD
?https://github.com/gregmagolan/repro-enable_bzlmod_breaks_workspace
Have you found anything relevant by searching the web?
Searched through Bazel issues and didn't see any duplicates.
Any other information, logs, or outputs that you want to share?
The text was updated successfully, but these errors were encountered: