`pip_parse` may fail if `PIP_REQUIRE_VIRTUALENV` is set

[EricCousineau-TRI]

🐞 bug report

Affected Rule

pip_parse() is the entry point we are using

Is this a regression?

Unsure

Description

I normally set export PIP_REQUIRE_VIRTUALENV=1 on my system. However, it seems to cause some rules to fail.

🔬 Minimal Reproduction

Unsure

🔥 Exception or Error

Repository rule whl_library defined at:
  .../external/rules_python/python/pip_install/pip_repository.bzl:650:30: in <toplevel>
ERROR: An error occurred during the fetch of repository 'my_pip_dep_requirements_gpustat':
   Traceback (most recent call last):
        File ".../external/rules_python/python/pip_install/pip_repository.bzl", line 626, column 13, in _whl_library_impl
                fail("whl_library %s failed: %s (%s)" % (rctx.attr.name, result.stdout, result.stderr))
Error in fail: whl_library my_pip_dep_requirements_gpustat failed: Collecting gpustat==1.1.1
  Using cached gpustat-1.1.1.tar.gz (98 kB)
  Installing build dependencies: started
  Installing build dependencies: finished with status 'error'
 (  error: subprocess-exited-with-error

  × pip subprocess to install build dependencies did not run successfully.
  │ exit code: 3
  ╰─> [1 lines of output]
      ERROR: Could not find an activated virtualenv (required).
      [end of output]

🌍 Your Environment

Operating System: Ubuntu 22.04

Output of bazel version:

  
Build label: 6.4.0
Build target: bazel-out/k8-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Thu Oct 19 17:07:43 2023 (1697735263)
Build timestamp: 1697735263
Build timestamp as int: 1697735263
  

Rules_python version:

  
0.19.0
  

Anything else relevant?

[EricCousineau-TRI]

To workaround, setting it to explicitly be empty in pip_parse works, e.g.:

pip_parse(
    name = "my_pip_dep_requirements",
    requirements_lock = "//:requirements.txt",
    environment = {
        "PIP_REQUIRE_VIRTUALENV": "",
    },
)

[aignas]

Note, that pip_parse is non-hermetic because it is a repository rule. I think your suggested workaround looks good. I'll close as not-planned to clear up the issue back log a little bit.