Use repo-relative labels wherever possible#9187
Merged
acozzette merged 2 commits intoprotocolbuffers:masterfrom Nov 4, 2021
Merged
Use repo-relative labels wherever possible#9187acozzette merged 2 commits intoprotocolbuffers:masterfrom
acozzette merged 2 commits intoprotocolbuffers:masterfrom
Conversation
The label `@com_google_protobuf//:foo` within the protobuf repo is often synonymous with just `//:foo`. We should prefer the latter as it allows us to use a shorter name for the module in the Bazel Central Registry (so just "protobuf" instead of "com_google_protobuf"). Note that the semantics can be subtle: in a macro, plain strings are anchored to the *calling* repo, so if we just use `//:foo` as the default value of a macro argument, it will be resolved to `@myrepo//:foo` if the macro is called from the repo `@myrepo`. In this case, it's necessary to directly call the `Label()` constructor to anchor the string label to the repo where the .bzl file lives. See bazelbuild/bazel-central-registry#28 (comment) for a bit more context.
Contributor
Author
|
Thanks, @Wyverald! |
Wyverald
added a commit
to bazelbuild/bazel-central-registry
that referenced
this pull request
Nov 4, 2021
Essentially a "cherrypick" of protocolbuffers/protobuf#9187
Wyverald
added a commit
to bazelbuild/bazel-central-registry
that referenced
this pull request
Nov 4, 2021
* Update protobuf with relative repo names patch Essentially a "cherrypick" of protocolbuffers/protobuf#9187 * Fix presubmit build target to demonstrate fix is working
acozzette
pushed a commit
to acozzette/protobuf
that referenced
this pull request
Mar 29, 2022
)" This reverts commit 11de748.
acozzette
pushed a commit
that referenced
this pull request
Mar 29, 2022
|
I went ahead and rolled this back on the 3.20.x branch (which will soon be merged to master), but I would be happy to roll it forward again if someone can help figure out a solution for #9688. |
musagracey
added a commit
to musagracey/bazel-central-registry
that referenced
this pull request
Aug 7, 2024
* Update protobuf with relative repo names patch Essentially a "cherrypick" of protocolbuffers/protobuf#9187 * Fix presubmit build target to demonstrate fix is working
stef-geo
pushed a commit
to stef-geo/bazel-central-registry
that referenced
this pull request
Jan 13, 2026
* Update protobuf with relative repo names patch Essentially a "cherrypick" of protocolbuffers/protobuf#9187 * Fix presubmit build target to demonstrate fix is working
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
The label
@com_google_protobuf//:foowithin the protobuf repo is often synonymous with just//:foo. We should prefer the latter as it allows us to use a shorter name for the module in the Bazel Central Registry (so just "protobuf" instead of "com_google_protobuf").Note that the semantics can be subtle: in a macro, plain strings are anchored to the calling repo, so if we just use
//:fooas the default value of a macro argument, it will be resolved to@myrepo//:fooif the macro is called from the repo@myrepo. In this case, it's necessary to directly call theLabel()constructor to anchor the string label to the repo where the .bzl file lives.See bazelbuild/bazel-central-registry#28 (comment) for a bit more context.