[6.2.0]Add native.module_{name,version} #17873
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Extension authors often want to write some macro and change its behavior depending on which module is using it. For example, for rules_go, they want to look at the `go_deps` tags in a certain module and only allow access to repos generated from those tags. We do this by introducing two new methods on `native`, callable only during the loading phase. They return the name and version of the module associated with the current repo. If the repo is from WORKSPACE, they return `None`. If the repo is generated by an extension, they return info about the module hosting the extension. The implementation works by storing the "associated module" information in `RepositoryMappingValue`. I had attempted to store them in `BzlmodRepoRuleValue` or even `RepositoryDirectoryValue`, but those are not the right places since they might happen before we even evaluate the MODULE.bazel file (i.e. for non-registry overrides). Fixes bazelbuild#17652. RELNOTES: Added `native.module_name()` and `native.module_version()` to allow BUILD macro authors to acquire information about which Bazel module the current repo is associated with. PiperOrigin-RevId: 518849334 Change-Id: I06b4bc95b5a57de2412ee02544240b054c708165
sgowroji
added
team-ExternalDeps
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Extension authors often want to write some macro and change its behavior depending on which module is using it. For example, for rules_go, they want to look at the
go_depstags in a certain module and only allow access to repos generated from those tags.We do this by introducing two new methods on
native, callable only during the loading phase. They return the name and version of the module associated with the current repo. If the repo is from WORKSPACE, they returnNone. If the repo is generated by an extension, they return info about the module hosting the extension.The implementation works by storing the "associated module" information in
RepositoryMappingValue. I had attempted to store them inBzlmodRepoRuleValueor evenRepositoryDirectoryValue, but those are not the right places since they might happen before we even evaluate the MODULE.bazel file (i.e. for non-registry overrides).Fixes #17652.
RELNOTES: Added
native.module_name()andnative.module_version()to allow BUILD macro authors to acquire information about which Bazel module the current repo is associated with.PiperOrigin-RevId: 518849334
Change-Id: I06b4bc95b5a57de2412ee02544240b054c708165