Mark internal deps as dev_depenencies so that downstream modules don't require those #1640
Conversation
| @@ -1,22 +1,22 @@ | |||
| module(name = "com_github_google_benchmark", version="1.8.2") | |||
| module(name = "google_benchmark", version="1.8.2") | |||
There was a problem hiding this comment.
will this break anything anywhere?
There was a problem hiding this comment.
No, actually it is the other way round - in the Bazel Central Registry, the module name must match the directory, and the convention there is not to use 'com_github' prefixes. So the unified name now is 'google_benchmark'.
| bazel_dep(name = "rules_cc", version = "0.0.6") | ||
| bazel_dep(name = "rules_python", version = "0.24.0") | ||
| bazel_dep(name = "googletest", version = "1.12.1", repo_name = "com_google_googletest") | ||
| bazel_dep(name = "rules_python", version = "0.24.0", dev_dependency = True) |
There was a problem hiding this comment.
i'm not sure this is a "dev" dependency as it's required to build the bindings.
There was a problem hiding this comment.
Yeah, I am torn on this as well. The question is how people will use the Python library in their projects (iff they rely on Bazel).
Since there is a PyPI package for this module, my assumption was this would be the preferred way of depending on the library, instead of pulling in the github source code and depending on the BUILD targets directly. But that is my personal speculation.
If you think the preferred way should be the second option, I am happy to remove it here.
WDYT?
There was a problem hiding this comment.
i think you're right. leave it as a dev dependency. thanks.
2 participants
bzlmod module dependencies support tagging specific upstream modules as internal. That means those are only used when actually working within the project, but those deps are not needed by other downstream modules depending on that said module.
This change will allow to directly use the
MODULE.bazelfile of thegoogle-benchmarkproject in the Bazel Central Registry.