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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4