-
Notifications
You must be signed in to change notification settings - Fork 323
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
Rename com_google_protobuf to protobuf #28
Conversation
Do we need to cherrypick your CL adding "protobuf" as a well-known module name into 5.0? Would people run into issues if they try to build Bazel with --experimental_enable_bzlmod? |
Good point, we should probably cherry-pick that. |
How does the cherry-pick work nowadays? Should I send a PR? |
Yeah, just send a PR to the release-5.0.0rc1 branch. |
Done at bazelbuild/bazel#14195 |
Context: bazelbuild/bazel-central-registry#28 RELNOTES: None PiperOrigin-RevId: 406334617
Oh no, I'm getting the following error while building Bazel:
This happens when the module name is different from the commonly used workspace name in the WORKSPACE file, because the repo itself will no longer be able to access targets of itself under the previous repo name... Maybe we need to add an attribute |
Modules can specify the workspace_name attribute to allow accessing its own targets under the repo name. This helps make migration easier when the preferred workspace name is different from the module name of the project. Context: bazelbuild/bazel-central-registry#28 (comment)
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.
* Use repo-relative labels wherever possible 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. * fix protobuf_deps.bzl
No description provided.