`package_annotation` `additive_build_content` doesn't add new target to pip hub repo
🐞 bug report
Affected Rule
Is this a regression?
Unknown, haven't used it before and didn't try older versions.
Description
Trying to add new target in existing pip dependency utilizing package_annotation and additive_build_content. BUILD file content is updated but target is not visible upon querying pip dependency targets.
I'm trying to add libtorch cc_library so my CPP code can depend on it.
🔬 Minimal Reproduction
This forked repo PR which extends existing example pip_repository_annotations contains changes required for reproduction. To reproduce:
- clone forked repo, checkout branch
new-target-in-pip-dep - go into
rules_python/examples/pip_repository_annotations - run
bazelisk build //... - query for targets in torch pip dependency with
bazelisk query @pip//torch:all, which returns:
@pip//torch:data
@pip//torch:dist_info
@pip//torch:pkg
@pip//torch:torch
@pip//torch:whl
Expectation is to have new target with label @pip//torch:libtorch as defined by cc_library... snippet mentioned above and can be seen in linked PR.
Note: contents of BUILD file are successfully updated, we can confirm be looking at examples/pip_repository_annotations/bazel-pip_repository_annotations/external/pip_torch/BUILD.bazel which contains cc_library... snippet at the end.
🌍 Your Environment
Operating System:
NAME="Ubuntu" VERSION="20.04.6 LTS (Focal Fossa)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 20.04.6 LTS" VERSION_ID="20.04"
Output of bazel version:
Bazelisk version: v1.19.0 Build label: 7.3.1 Build target: @@//src/main/java/com/google/devtools/build/lib/bazel:BazelServer Build time: Mon Aug 19 16:12:50 2024 (1724083970) Build timestamp: 1724083970 Build timestamp as int: 1724083970
Rules_python version:
Recently forked main branch.
A workaround is to use the Label @pip_torch//:my_added_target.
@aignas thanks, it works.
When you say it's workaround do you mean it's not the ideal way to do it but currently only possible way and should be fixed in future?
I meant that this is a way to get it working.
Another option would be to use whl_filegroup rule to extract the libs from the whl target and then create a cc_library like that. That is working for numpy headers, and it could work here.
I personally don't have time to do design and code on this, but I am happy to mentor someone to come up with a solution for this.
On 9 September 2024 17:58:40 GMT+09:00, klbrvik @.***> wrote:
@aignas thanks, it works.
When you say it's workaround do you mean it's not the ideal way to do it but currently only possible way and should be fixed in future?
-- Reply to this email directly or view it on GitHub: https://github.com/bazelbuild/rules_python/issues/2187#issuecomment-2337534666 You are receiving this because you were mentioned.
Message ID: @.***>