PEP 704 - Require virtual environments by default for package installers

[brettcannon]

@CAM-Gerlach

This means only one venv can be placed in a given directory, which may or may not interoperate with existing centralized management approaches, as now all conforming venvs will need a unique parent directory too.

Most of the systems I have come across that try to manage multiple virtual environments by name are managed from some global directory (otherwise it’s an ad-hoc situation or it’s a tool that hides virtual environments from you like Nox and tox).

@konstin

Open Question (and possibly an entry for the Rejected Ideas section): If a cli tool sees a .venv but it isn’t activated, should it just use that anyway (vs. saying “please run source .venv/bin/activate and try again”)

That’s what the Python Launcher for Unix does and works out rather nicely in my opinion. Since this PEP doesn’t talk about execution and only installation, I don’t think it has any bearing on this specific case beyond helping standardize on virtual environment names.

@steve.dower

So it feels like it’s solely motivated to get PEP 582 rejected by using process.

I think that’s prescribing a specific motivation a bit too much. Pradyun may also be trying to the force some decision be made about virtual environments by providing an alternative to PEP 582, but not necessarily favouring one over the other.

@dstufft

Maybe some people will do that even with it being couched more in terms of a recommendation, but at least a recommendation carries with it some sense or understanding that you are allowed to do something different.

I think it’s reasonable to make sure this PEP is phrased as a recommendation for installers that we think should be followed.

I personally see three three levels of possibility here:

1. What this PEP proposes (but potentially toned down to a recommendation), which is require an environment by default with some sort of opt-out (e.g. PIP_REQUIRE_VIRTUALENV=1 is the assumed default).
2. If a virtual environment is …
   a. … found and is unambiguous, use it automatically (i.e. sort of like implicit environment activation).
   b. … found and it’s ambiguous which virtual environment to use, error out.
   c. … not found, continue doing what happens today and lean on PEP 668.
3. Status quo

Option 2 would require standardizing on virtual environment locations which I’m selfishly an advocate for since, from a tools perspective, it’s just a mess to try and support the myriad of places people put their virtual environments. I have Support a way for other tools to assist in environment/interpreter discovery · brettcannon/python-launcher · Discussion #168 · GitHub for this, but for more common, simpler situations we could try to handle via standards instead of dynamically executed code.