`package_annotation` `additive_build_content` doesn't add new target to pip hub repo

[klbrvik]

🐞 bug report

Affected Rule

pip_parse 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:

1. clone forked repo, checkout branch new-target-in-pip-dep
2. go into rules_python/examples/pip_repository_annotations
3. run bazelisk build //...
4. 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.

[aignas]

A workaround is to use the Label @pip_torch//:my_added_target.

[klbrvik]

@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?

[aignas]

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: #2187 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>