Skip to content
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

Closed
fmeum opened this issue Jan 1, 2023 · 11 comments
Closed

Allow module extensions to check whether a tag is a dev dependency #17101

fmeum opened this issue Jan 1, 2023 · 11 comments
Labels
area-Bzlmod Bzlmod-specific PRs, issues, and feature requests P2 We'll consider working on this in future. (Assignee optional) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: feature request

Comments

@fmeum
Copy link
Collaborator

fmeum commented Jan 1, 2023

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:

  1. A module extension may want to emit a list of repos the root module should bring into scope with use_repo, but dev dependencies have to be brought into scope with a use_repo call on a module extension proxy created with dev_dependency = True.
  2. Module extensions wrapping external package managers may want to use this information when associating license metadata with packages.

Which operating system are you running Bazel on?

Any

What is the output of bazel info release?

6.0.0

If bazel info release returns development 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

@fmeum
Copy link
Collaborator Author

fmeum commented Jan 1, 2023

@meteorcloudy @Wyverald I would be interested in hearing your thoughts on whether this should be possible.

@sgowroji sgowroji added team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: feature request untriaged labels Jan 1, 2023
@meteorcloudy
Copy link
Member

Can you explain a bit why having dev_dependency for the module extension proxy call isn't enough? Under which use case, do we have to share dev and non-dev dependencies with the same module extension proxy call?

@fmeum
Copy link
Collaborator Author

fmeum commented Jan 2, 2023

Having the dev_dependency parameter on use_extension is indeed enough as users can just create a new proxy when they want to add a different type of dependency.

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 dev_dependency = True available to the module extension.

The very concrete use case I have for this information is the auto_use_repo idea mentioned in #17048. If a module extension wants to emit the correct use_repo calls that should be made in the root module's MODULE.bazel, it has to be able to distinguish tags from dev and non-dev proxies.

@meteorcloudy
Copy link
Member

I understand the idea of auto_use_repo, but have no idea how it should work (neither on how Gazelle's update-repos rep o works). I thought since the tags can only be used via the extension proxy created by use_extension, we shouldn't need the dev_dependency = True on tags?

@fmeum
Copy link
Collaborator Author

fmeum commented Jan 2, 2023

Let's consider the following example MODULE.bazel of a root module:

foo_deps = use_extension("@rules_foo//foo:extensions.bzl", "foo_deps")
foo_deps.package(name = "fmt")
foo_deps.package(name = "json")
# Managed by auto_use_repo
use_repo(foo_deps, "fmt", "json")

foo_dev_deps = use_extension("@rules_foo//foo:extensions.bzl", "foo_deps", dev_dependency = True)
foo_dev_deps.package(name = "testing")
# Managed by auto_use_repo
use_repo(foo_dev_deps, "testing")

In this situation, the foo_deps extension would create a repository with a file that contains a list of all repos added due to tags defined by the root module. auto_use_repo could consume the list and ensure that the use_repo calls are up to date.

However, with the currently available features, foo_deps can't know that testing is a dev dependency and should thus be added to the use_repo(foo_dev_deps, ...) call whereas fmt is a regular dependency and thus has to be added to the use_repo(foo_deps, ...) call.

One way to fulfill this feature request would be to add module_ctx.is_dev_dependency(module_tag), which would return True if and only if the argument is a module tag created by a module extension proxy in turn created by a call to use_extension with dev_dependency = True. If that were available, foo_deps could create the following repositories.json file that auto_use_repo could use to add the used repositories to the correct use_repo call:

[{"name": "fmt"}, {"name": "json"}, {"name": "testing", "dev_dependency": true}]

I expect this to be useful in other situation, such as if foo_deps wants to add usage or license metadata to the repositories it creates.

@Wyverald
Copy link
Member

Wyverald commented Jan 2, 2023

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.

@meteorcloudy
Copy link
Member

Thanks!! Do I understand it correctly that we probably don't need to add dev_dependency to the tag API, but implementing module_ctx.is_dev_dependency is enough?

@fmeum
Copy link
Collaborator Author

fmeum commented Jan 3, 2023

Thanks!! Do I understand it correctly that we probably don't need to add dev_dependency to the tag API, but implementing module_ctx.is_dev_dependency is enough?

Yes, exactly. Tags are already implicitly dev dependencies if they come from a proxy that is marked with dev_dependency, so I don't think adding dev_dependency to tags would increase expressivity.

@Wyverald Wyverald added P2 We'll consider working on this in future. (Assignee optional) area-Bzlmod Bzlmod-specific PRs, issues, and feature requests and removed untriaged labels Jan 17, 2023
@github-actions
Copy link

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".

@github-actions github-actions bot added the stale Issues or PRs that are stale (no activity for 30 days) label Feb 17, 2023
@fmeum
Copy link
Collaborator Author

fmeum commented Feb 17, 2023

Not stale

@sgowroji sgowroji removed the stale Issues or PRs that are stale (no activity for 30 days) label Feb 17, 2023
@meteorcloudy meteorcloudy added the awaiting-bazeler Awaiting a response from the Bazel team label Feb 20, 2023
fmeum added a commit to fmeum/bazel that referenced this issue Mar 29, 2023
Allows module extensions to determine whether a given tag represents a
dev dependency.

Fixes bazelbuild#17101
Work towards bazelbuild#17908
fmeum added a commit to fmeum/bazel that referenced this issue Mar 29, 2023
Allows module extensions to determine whether a given tag represents a
dev dependency.

Fixes bazelbuild#17101
Work towards bazelbuild#17908
@Wyverald
Copy link
Member

@bazel-io fork 6.2.0

@Wyverald Wyverald removed the awaiting-bazeler Awaiting a response from the Bazel team label Mar 30, 2023
ShreeM01 pushed a commit to ShreeM01/bazel that referenced this issue Mar 30, 2023
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
Wyverald pushed a commit that referenced this issue Mar 31, 2023
* 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 <fabian@meumertzhe.im>
Co-authored-by: keertk <keerthanakumar@google.com>
fweikert pushed a commit to fweikert/bazel that referenced this issue May 25, 2023
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-Bzlmod Bzlmod-specific PRs, issues, and feature requests P2 We'll consider working on this in future. (Assignee optional) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: feature request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants