-
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
Allow module extensions to check whether a tag is a dev dependency #17101
Comments
@meteorcloudy @Wyverald I would be interested in hearing your thoughts on whether this should be possible. |
Can you explain a bit why having |
Having the This feature request is only about making the information that a certain proxy (in particular, the set of tags created with it) was created with The very concrete use case I have for this information is the |
I understand the idea of |
Let's consider the following example
In this situation, the However, with the currently available features, One way to fulfill this feature request would be to add [{"name": "fmt"}, {"name": "json"}, {"name": "testing", "dev_dependency": true}] I expect this to be useful in other situation, such as if |
Thanks for the example -- that helped me understand the use case better. I'd like to think a bit more about how the API should look like. |
Thanks!! Do I understand it correctly that we probably don't need to add |
Yes, exactly. Tags are already implicitly dev dependencies if they come from a proxy that is marked with |
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 |
Allows module extensions to determine whether a given tag represents a dev dependency. Fixes bazelbuild#17101 Work towards bazelbuild#17908
Allows module extensions to determine whether a given tag represents a dev dependency. Fixes bazelbuild#17101 Work towards bazelbuild#17908
@bazel-io fork 6.2.0 |
Allows module extensions to determine whether a given tag represents a dev dependency. Fixes bazelbuild#17101 Work towards bazelbuild#17908 Closes bazelbuild#17909. PiperOrigin-RevId: 520645663 Change-Id: I3e3136a09d01d25fc706bcd0dfd7e53b6e7d5285
* Add `module_ctx.is_dev_dependency` Allows module extensions to determine whether a given tag represents a dev dependency. Fixes #17101 Work towards #17908 Closes #17909. PiperOrigin-RevId: 520645663 Change-Id: I3e3136a09d01d25fc706bcd0dfd7e53b6e7d5285 * Revert section that was accidentally cherry-picked --------- Co-authored-by: Fabian Meumertzheim <[email protected]> Co-authored-by: keertk <[email protected]>
Allows module extensions to determine whether a given tag represents a dev dependency. Fixes bazelbuild#17101 Work towards bazelbuild#17908 Closes bazelbuild#17909. PiperOrigin-RevId: 520645663 Change-Id: I3e3136a09d01d25fc706bcd0dfd7e53b6e7d5285
Description of the feature request:
With Bzlmod, a module extension should be able to check whether the extension proxy that was used to add a given module tag had
dev_dependency = True
or not.What underlying problem are you trying to solve with this feature?
While this information isn't directly required to resolve dependencies, the distinction in prod and dev dependencies becomes important in a umber of situations:
use_repo
, but dev dependencies have to be brought into scope with ause_repo
call on a module extension proxy created withdev_dependency = True
.Which operating system are you running Bazel on?
Any
What is the output of
bazel info release
?6.0.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 master; git rev-parse HEAD
?No response
Have you found anything relevant by searching the web?
#17048
Any other information, logs, or outputs that you want to share?
No response
The text was updated successfully, but these errors were encountered: