Use repo-relative labels wherever possible #9187
Merged
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//: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 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.