-
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
Bazel crashes using external aspect + --noenable_workspace
#22691
Comments
Thank you for the crystal clear repro instructions! Looking now. |
The crux of the issue is that we have no way to figure out the repo mapping of Now, it's not completely clear to me what the correct behavior should be. What should we use as the repo mapping of In any case, we definitely shouldn't crash. So this is still a legit bug. |
I have no direct use for it. However, the Bazel plugin for Intellij yes.
I mitigated the problem by configuring the option |
Looking at the aspect source, I think that IntelliJ should be using |
Problem is that We did discuss this with the JetBrains people before, especially as they might want to support e.g. providers in cc @agluszak |
I think that the following could work:
|
So to be clear the current workaround is to do |
In this Slack conversation with @tpasternak we realized that |
unused_deps is also affected by this problem. |
Otherwise `"<root>"` ends up being escaped with Unicode escape sequences, which is unnecessarily complex. Work towards bazelbuild#22691 Closes bazelbuild#23785. PiperOrigin-RevId: 680633877 Change-Id: Ic3c90c33bbf1209efa90be78b432e2132f0a1f05
* Disable bazel deps call. It's unused yet, and could fail bazelbuild/bazel#22691
This allows IDEs to query for the direct dependencies of the root module as well as how they can refer to them from the point of view of the root module. Also always emit `name` and `version` so that consumers don't have to know how to parse module keys. Work towards #22691 Closes #23787. PiperOrigin-RevId: 693453084 Change-Id: Ie3fd5e89301d8e83d0eaa686188634923853f01a
This allows IDEs to query for the direct dependencies of the root module as well as how they can refer to them from the point of view of the root module. Also always emit `name` and `version` so that consumers don't have to know how to parse module keys. Work towards bazelbuild#22691 Closes bazelbuild#23787. PiperOrigin-RevId: 693453084 Change-Id: Ie3fd5e89301d8e83d0eaa686188634923853f01a
…4234) This allows IDEs to query for the direct dependencies of the root module as well as how they can refer to them from the point of view of the root module. Also always emit `name` and `version` so that consumers don't have to know how to parse module keys. Work towards #22691 Closes #23787. PiperOrigin-RevId: 693453084 Change-Id: Ie3fd5e89301d8e83d0eaa686188634923853f01a Commit 1003d2c Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>
…4234) This allows IDEs to query for the direct dependencies of the root module as well as how they can refer to them from the point of view of the root module. Also always emit `name` and `version` so that consumers don't have to know how to parse module keys. Work towards #22691 Closes #23787. PiperOrigin-RevId: 693453084 Change-Id: Ie3fd5e89301d8e83d0eaa686188634923853f01a Commit 1003d2c Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>
Folks, please correct me if I'm wrong - we still need to wait for the |
Yes. The other required PR, the one that adds apparent names to |
Suggest the new flag instead of crashing when `--override_repository` is applied to a non-existent repo with `--noenable_workspace`. Fixes #22691 RELNOTES: The new `--inject_repository` flag can be used to add new repositories via the CLI with `--enable_bzlmod`. Such repositories behave as if they were declared by `local_repository` via `use_repo_rule` in the root module. Closes #23791. PiperOrigin-RevId: 695848897 Change-Id: I92ed25261c92d07f289815fcf6a65485ff43f373
…stent repo (#24301) Suggest the new flag instead of crashing when `--override_repository` is applied to a non-existent repo with `--noenable_workspace`. Fixes #22691 RELNOTES: The new `--inject_repository` flag can be used to add new repositories via the CLI with `--enable_bzlmod`. Such repositories behave as if they were declared by `local_repository` via `use_repo_rule` in the root module. Closes #23791. PiperOrigin-RevId: 695848897 Change-Id: I92ed25261c92d07f289815fcf6a65485ff43f373 Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>
Thank you. It looks we are now unblocked and can move forward. However I noticed a few interesting things releated to inject repository:
|
This is expected: With Bzlmod, canonical names should always be managed by Bazel itself to ensure that they can't collide. That's why your injected repo
I will look into this, but note that these commands generally show information about modules, not repos, by default. |
Thank you! |
A fix for this issue has been included in Bazel 8.0.0 RC3. Please test out the release candidate and report any issues as soon as possible. |
This allows IDEs to query for the direct dependencies of the root module as well as how they can refer to them from the point of view of the root module. Also always emit `name` and `version` so that consumers don't have to know how to parse module keys. Work towards bazelbuild#22691 Closes bazelbuild#23787. PiperOrigin-RevId: 693453084 Change-Id: Ie3fd5e89301d8e83d0eaa686188634923853f01a
Suggest the new flag instead of crashing when `--override_repository` is applied to a non-existent repo with `--noenable_workspace`. Fixes bazelbuild#22691 RELNOTES: The new `--inject_repository` flag can be used to add new repositories via the CLI with `--enable_bzlmod`. Such repositories behave as if they were declared by `local_repository` via `use_repo_rule` in the root module. Closes bazelbuild#23791. PiperOrigin-RevId: 695848897 Change-Id: I92ed25261c92d07f289815fcf6a65485ff43f373
Description of the bug:
With bzlmod and the --noenable_workspace option, Bazel crashes when we try to use an external aspect defined by the --aspects and --override_repository options.
--enable_workspace
option.--aspects
option, e.g--aspects=@@foo//:xxx.bzl%foo_aspect
.--aspects
option, e.g--aspects=@@foo//:foo.bzl%xxx
.7.1.2
.Which category does this issue belong to?
Core, External Dependency
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
.bazelversion
BUILD.bazel
foo/foo.bzl
foo/WORKSPACE
MODULE.bazel
WORKSPACE
Which operating system are you running Bazel on?
Linux / amd64
What is the output of
bazel info release
?release 7.2.0
If
bazel info release
returnsdevelopment version
or(@non-git)
, tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse HEAD
?No response
If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.
No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response
The text was updated successfully, but these errors were encountered: