[Python-Dev] Proposing the deprecation of the pyvenv script (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sat Sep 19 06:23:07 CEST 2015

On 19 September 2015 at 01:16, Barry Warsaw <barry at python.org> wrote:

On Sep 18, 2015, at 07:53 PM, Nick Coghlan wrote:

I currently use pyvenv directly, but I agree with starting a migration to only supporting the more explicit "python -m venv". There's always an inherent ambiguity on *nix with unqualified version sensitive Python commands as to whether they're referring to Python 2 or 3, as the answer often depends on how old the particular script is (e.g. pip and virtualenv relate to the Python 2 installation, while pyvenv relates to the Python 3 installation). On Debian, we often use things like -2 or -3 suffixes, but there's no naming standard, and you inevitably get to monstrosities like nose2-3. ;) For scripts which have to be Python-version specific, the slight loss of usability for python -m blah outweighs the ambiguity and ugliness of the direct alternative. There's one slightly oddity in the migration, which is that "pyvenv" will still run even if you're in an activated Python 2 virtual environment, while "python -m venv" fails. The answer is to use a qualified Python version in the latter call. One thing that came up in a similar discussion is pip, and the suggested move to python -m pip, which makes a lot of sense. However, inside a virtualenv, there's no ambiguity about the Python version associated with direct pip invocation, so it still makes sense to install that there.

Right. This is moving more into python-ideas and/or distutils-sig territory, but this point also gave me an idea regarding what we might want to do with the "python" command on Linux systems that have migrated to using Python 3 as the system Python: what if we agreed to change "python" on Linux systems to be a script that launches a "default" virtual environment stored in the user's home directory (location TBD), and similarly changed the unqualified system "pip" command to manipulate that default virtual environment?

The question of "Which Python does 'python' run and 'pip' manipulate?" would then be determined by how that default virtual environment was set up rather than using a distro specific runtime switching technology. If could either be Python 2.7 based using virtualenv, or else a native Python 3 venv. Switching to a different default runtime (e.g. PyPy) would be a matter of replacing that default virtual environment with one created using a different interpreter. (This approach would likely also deal with the perennial "Should pip default to --user for global installs?" question).

Presumably, we could figure out a way to make that work on Windows as well, such that "python" and "pip" always meant activating and working in the user's default virtual environment, if there wasn't already a virtual environment activated.

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list