`compile_pip_requirements` does not forward `data` attribute to the generated `py_binary`

[granatam]

🐞 bug report

Affected Rule

The issue affects the compile_pip_requirements rule/macro.

Is this a regression?

I believe this is not a regression.

Description

I'm trying to pass a custom certificate file to compile_pip_requirements via extra_args using --cert=$(location ...).

The compile_pip_requirements macro accepts a data attribute, but it looks like this attribute is not forwarded to the internal py_binary target generated for the .update target.

As a result, using $(location :pip_cert) inside extra_args fails during analysis because the generated py_binary does not declare :pip_cert as a prerequisite.

🔬 Minimal Reproduction

load("@rules_python//python:pip.bzl", "compile_pip_requirements")

filegroup(
    name = "pip_cert",
    srcs = ["pip.cert"],
)

compile_pip_requirements(
    name = "requirements",
    src = "requirements.in",
    extra_args = ["--cert=$(location :pip_cert)"],
    requirements_txt = "requirements_lock.txt",
    data = [":pip_cert"],
)

🔥 Exception or Error

ERROR: .../BUILD.bazel:8:25: in args attribute of py_binary rule //:requirements.update: label '//:pip_cert' in $(location) expression is not a declared prerequisite of this rule. Since this rule was created by the macro 'pip_compile', the error might have been caused by the macro implementation
ERROR: .../BUILD.bazel:8:25: Analysis of target '//:requirements.update' (config: 7f8856b) failed
ERROR: Analysis of target '//:requirements.update' failed; build aborted

🌍 Your Environment

Operating System: Ubuntu/MacOS.

Output of bazel version:

  
$ bazel version
Build label: 8.5.1-homebrew
Build target: @@//src/main/java/com/google/devtools/build/lib/bazel:BazelServer
Build time: Tue Jan 01 00:00:00 1980 (315532800)
Build timestamp: 315532800
Build timestamp as int: 315532800
  

Rules_python version: tested with rules_python from the main branch, approximately version 2.0.3.

Anything else relevant?

I see two possible ways to address this:

1. Forward the data attribute to the generated py_binary target.
2. Add a dedicated label attribute, e. g. ssl_cert, and let the rule/macro generate the corresponding --cert=$(location ...) argument internally.

The first option seems important regardless of whether a dedicated certificate attribute is added. The compile_pip_requirements macro accepts data, so I would expect files listed there to be available to the generated executable target. Without that, using data together with extra_args is confusing.

The second option would make the certificate use case easier, but it would not fully solve the problem. extra_args may need to reference other files too, not only certificates. For that reason, forwarding data still seems necessary.