regression: pip_compile ignores env attribute

[kpark-hrp]

🐞 bug report

Affected Rule

The issue is caused by the rule: pip_compile but exposed to public as compile_pip_requirements

During this change below, env parameter used to be captured by kwargs and then passed as attrs to respective py_binary. But now env within kwargs is being ignored, so any environment variables that is set with pip_compile rule is being ignored.

e923f9e#diff-a92cc6468f47191b8e22d4bbe2564d3968d3dd4bbc383b9f3df3c4c520e1583eL147-R165

Is this a regression?

Yes. env parameter that was passed to pip_compile was respected in 0.34.0 but now it's not on 0.36.0.

Description

A clear and concise description of the problem...

🔬 Minimal Reproduction

compile_pip_requirements(
    ...,
    env = {
        "PIP_CONFIG_FILE": "<path>",
    },
    ...
)

Then run bazel run :requirements.update on 0.34.0 vs 0.36.0

🔥 Exception or Error

No particular exception, but the environment variables are not picked up when running bazel run :requirements.update

🌍 Your Environment

Operating System: MacOS 14.7

Output of bazel version: bazel 6.5.0

Rules_python version: 0.34.0 trying to upgrade to 0.36.0

[aignas]

FYI @cj81499 and @lpulley.

[lpulley]

Whipped up #2277. Haven't tested it yet, but does it seem reasonable thus far?

[lpulley]

I'm not sure there's a great way to write a test for this, but the X.update and X_test targets are the same except that X_test gets a different env and gets **kwargs passed through.

I did test an X.update by hand on my patch with

env = {"CUSTOM_COMPILE_COMMAND": "__TEST_REQUIREMENTS_CUSTOM_COMPILE_COMMAND__"}

and that works as expected, so I think it'll fix this issue.