So with PEX supporting `--exclude` now I'm thinking of picking back up the work to support extending python dep inference to support environment-provided dependencies. My first go at this tried to create a union rule around this in the python graph building code. But it looked a bit complicated to actually implement that and I'm wondering if there might be a better way? This would be an absolute game changer for our team to be able to use this, so I'm very interested in trying. But it might be useful to get some more feedback on the best way to implement this first.

Brainstorm idea: • some metadata on a

python_requirement

marking it as excluded (maybe not the best, eg should a test target use it for real?) • Some metadata on targets that use pex (packages, tests, etc) to mark certain requirements as excluded

another wild idea I had a while ago is to see if PEX / pip could use some flags to create a virtual environment by bringing the system site-packages along?

❯ python3 -m venv pure-venv; source pure-venv/bin/activate; python3 -m pip list
Package    Version
---------- -------
pip        22.2.2
setuptools 62.6.0
 
❯ python3 -m venv --system-site-packages greedy-venv; source greedy-venv/bin/activate; python3 -m pip list
Package                   Version
------------------------- -----------
ansicolors                1.1.8
argcomplete               2.0.0
astroid                   2.12.14
attrs                     22.1.0
Authlib                   1.2.0
Babel                     2.10.3
bcrypt                    3.2.2
Beaker                    1.12.1
beautifulsoup4            4.12.2
...

if Pants can create venvs like this, perhaps we can use it normally? I.e. the packages installed into the global site-packages by RPM packages would be just available OOTB in the sandboxed venv Pants will use to run tests / type checks etc?

OOTB?

Out of the box, sorry

I think I still want to be able to map imports to something. Metadata on the

python_requirement

target sounds like a start, but I don't think that's very extensible if we want to get into specifying what a provider backend might look like. My thought was to have a

${provider}_python_requirement()

target and provide some plugin API that would let integrators have some ability to let Pants at least ask the environment if they provide this option (if that is desired). This could bottom out on "trust me" and potentially even have a

provided_python_requirement

but I don't want to limit it to that