-
Notifications
You must be signed in to change notification settings - Fork 120
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
When using the bazel module, how to define the refresh_command in BUILD #189
Comments
A workaround fix is add bazel-compile-commands-extractor to bzr, and we treat it as a full dependency. |
@cpsauer , Even with the dev_dependency as in here See https://buildkite.com/bazel/bcr-presubmit/builds/5552#018f8b08-67ea-42d6-86f9-3476a05b8de6 |
Thanks so much for reporting, guys. I think I get it--and I've got an idea. |
Would it work to break out the refresh_compile_commands call into a separate BUILD file? Say //dev_tools:BUILD? |
To explain: I think this is an instance of more general trickiness around dev_dependencies in bzlmod--with the general case being discussed here. |
I agree that it's a bit janky, but making it a non-dev-dependency is probably not something you want either, for the reasons in this issue. It's likely that we'll end up depending on rules_python again soon and better to not bring in a ton of unneeded deps for folks. And I'm loathe to do the BCR approach sinc it's (AFAIK) irreversible and would meaningfully complicate releasing. |
Please let me know if that alternative approach might work. And sorry about the pain here. This isn't a case I'd considered or heard about before--and I really appreciate your taking the time to explore and explain |
If that does fix things, please don't close just yet. We should update the readme to guide people around this. |
It seems like the same problem was already identified several month ago here : bazelbuild/bazel-central-registry#1503 @fmeum, @alexeagle, do you have an opinion about this issue ? |
Yes, #189 (comment) sounds right to me. Dev tooling for a module ideally should not live in packages that are consumed by module users. |
I believe that at least one version shall be published in the BCR, and be used as dev_dependency. |
^ What do you think about the potential solution above, also recommended by fmeum? |
This is what I'm using in my MODULE.bazel file. We have converted to a 100% module based build:
|
For the document,
Open a BUILD file—we'd recommend using (or creating) //BUILD—and add something like:
Hessian2-codec
is the bazel-compile-commands-extractor‘s user. Recently the pr convert the repo to bazel module. But we have met some question.As a library, we are meant to be referenced by other projects. Due to the use of the bazel module, bazel regards the repository with git_override as a dev_dependency. As a result, it cannot be used by users who depend on hessian2-codec. It will throw the exception like
ERROR: error loading package '@@hessian2-codec~//': Unable to find package for @@[unknown repo 'hedron_compile_commands' requested from @@hessian2-codec~]//:refresh_compile_commands.bzl: The repository '@@[unknown repo 'hedron_compile_commands' requested from @@hessian2-codec~]' could not be resolved: No repository visible as '@hedron_compile_commands' from repository '@@hessian2-codec~'.
Failure will occur when loading the build file for hessian2-codec.
Regarding defining refresh_command in the bazel module, are there any best practices?
The text was updated successfully, but these errors were encountered: