What's the deal with the pipx shared venv, exactly?

[pf_moore (Paul Moore)]

@kknechtel

Notable from that discussion:

@pf_moore

Probably the biggest thing that has come out of this discussion so far is that I want to explicitly add a note that pip does not support being quoted as a dependency of other tools (because it has no supported Python API).

So maybe what’s needed is a tool that actually does have that API - and is minimal and focused. Or maybe just the library for it, never mind making a(nother) competitor to Pip. (Or maybe in the far future, Pip could use something like that internally.)

I’m not actually sure I still feel that way, to be honest. IMO it’s legitimate for code that expects to be able to run python -m pip as a subprocess (using sys.executable as the Python interpreter) to declare pip as a runtime dependency. Pip does have an API - it’s the CLI. What I said was it has no Python API, i.e., there are no supported functions importable or callable from the user’s Python code. But that’s a pretty fine distinction, and I didn’t want to derail the discussion by expanding on that point.

So, to put all this in context, nowadays, pipx could happily add a dependency on pip and/or uv, then use the command line interface for whichever tool the user prefers, including the --python flag, to install the requested application in its private venv. And I’m pretty sure there’s work going on in that direction.