PEP 486: Make the Python Launcher aware of virtual environments
On 12 February 2015 at 14:46, Paul Moore <p.f.moore@gmail.com> wrote:
If py.exe detected when the environment variable VIRTUAL_ENV was set, and used that virtualenv as the default Python rather than the "system" python it normally used, this would be perfect.
I think I'll write a PEP for this. Do people think it's a reasonable idea?
OK, here we go. https://www.python.org/dev/peps/pep-0486/ Reproduced inline below for ease of reading / commenting. It's also available on github at https://github.com/pfmoore/peps should people want to submit corrections or anything there. PEP: 486 Title: Make the Python Launcher aware of virtual environments Version: $Revision$ Last-Modified: $Date$ Author: Paul Moore <p.f.moore@gmail.com> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 12-Feb-2015 Python-Version: 3.5 Post-History: Abstract ======== The Windows installers for Python include a launcher that locates the correct Python interpreter to run (see PEP 397). However, the launcher is not aware of virtual environments (virtualenv [1]_ or PEP 405 based), and so cannot be used to run commands from the active virtualenv. This PEP proposes making the launcher "virtualenv aware". This means that when run without specifying an explicit Python interpreter to use, the launcher will use the currently active virtualenv, if any, before falling back to the configured default Python. Rationale ========= Windows users with multiple copies of Python installed need a means of selecting which one to use. The Python launcher provides this facility by means of a ``py`` command that can be used to run either a configured "default" Python or a specific interpreter, by means of command line arguments. So typical usage would be:: # Run the Python interactive interpreter py # Execute an installed module py -m pip install pytest py -m pytest When using virtual environments, the ``py`` launcher is unaware that a virtualenv is active, and will continue to use the system Python. So different command invocations are needed to run the same commands in a virtualenv:: # Run the Python interactive interpreter python # Execute an installed module (these could use python -m, # which is longer to type but is a little mopre similar to the # launcher approach) pip install pytest py.test Having to use different commands is is error-prone, and in many cases the error is difficult to spot immediately. The PEP proposes making the ``py`` command usable with virtual environments, so that the first form of command can be used in all cases. Implementation ============== Both ``virtualenv`` and the core ``venv`` module set an environment variable ``VIRTUAL_ENV`` when activating a virtualenv. This PEP proposes that the launcher checks for the ``VIRTUAL_ENV`` environment variable whenever it would run the "default" Python interpreter for the system (i.e., when no specific version flags such as ``py -2.7`` are used) and if present, run the Python interpreter for the virtualenv rather than the default system Python. The "default" Python interpreter referred to above is (as per PEP 397) either the latest version of Python installed on the system, or a version configured via the ``py.ini`` configuration file. When the user specifies an explicit Python version on the command line, this will always be used (as at present). Impact on Script Launching ========================== As well as interactive use, the launcher is used as the Windows file association for Python scripts. In that case, a "shebang" (``#!``) line at the start of the script is used to identify the interpreter to run. A fully-qualified path can be used, or a version-specific Python (``python3`` or ``python2``, or even ``python3.5``), or the generic ``python``, which means to use the default interpreter. With the proposed change, scripts that start with ``#!python`` (or one of its equivalent forms) will be run using an active virtualenv. This is a change in behaviour, although it will only affect users running scripts from the command line with a virtualenv activated. Under Unix, the ``#!/usr/bin/env python`` shebang line will use the version of Python found on ``$PATH``, whereas ``#!/usr/bin/python`` will use the system Python. In order to match Unix behaviour as closely as possible, it is proposed that the two shebang forms:: #!/usr/bin/env python #!python use an active virtualenv, if present, whereas the forms:: #!/usr/bin/python #!/usr/local/bin/python use *only* the default system Python, and ignore the ``VIRTUAL_ENV`` environment variable. Exclusions ========== The PEP makes no attempt to promote the use of the launcher for running Python on Windows. Most existing documentation assumes the user of ``python`` as the command to run Python, and (for example) ``pip`` to run an installed Python command. This documentation is not expected to change, and users who choose to manage their ``PATH`` environment variable can continue to use this form. The focus of this PEP is purely on allowing users who prefer to use the launcher when dealing with their system Python installations, to be able to continue to do so when using virtual environments. References ========== .. [1] https://virtualenv.pypa.io/ Copyright ========= This document has been placed in the public domain.
Looks well thought-out. +1 -- ~Ethan~
On 13 February 2015 at 05:47, Ethan Furman <ethan@stoneleaf.us> wrote:
Looks well thought-out.
+1
I don't see any holes in the proposed behaviour either, so +1 from me. Procedurally, since it's a Windows specific change, and assuming Guido doesn't want to pronounce on this one himself, perhaps Steve Dower would be an appropriate BDFL-Delegate? Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 13 February 2015 at 07:02, Nick Coghlan <ncoghlan@gmail.com> wrote:
Procedurally, since it's a Windows specific change, and assuming Guido doesn't want to pronounce on this one himself, perhaps Steve Dower would be an appropriate BDFL-Delegate?
The PEP is now up to date and the patch is on the tracker at http://bugs.python.org/issue23465. There's not been any further questions or comments, so I think I'm happy with it. As Guido's now away (I gather) I'll wait till he gets back and then post a formal request for pronouncement (or appointment of a BDFL-Delegate to pronounce). If anyone has any issues with the PEP, please speak up before then! Paul
On 12 February 2015 at 19:44, Paul Moore <p.f.moore@gmail.com> wrote:
Impact on Script Launching ==========================
Now that I'm looking into the details of the code for the launcher, I've noticed that a shebang line of "#!/usr/bin/env python" will first of all search PATH for a python executable, before falling back to the default Python. This is *not* specified in PEP 397, although it makes sense (as it parallels the behaviour in Unix). Given that this behaviour exists, doing an explicit check for VIRTUAL_ENV during shebang processing is unnecessary. The same effect can be gained just by using "#!/usr/bin/env python" (it won't cover the case of someone setting VIRTUAL_ENV but *not* adding it to PATH, but that's no great loss). I propose simply dropping this section of the PEP. I'll replace it with a note explaining why it was dropped, and explaining the behaviour of /usr/bin/env. Is that sufficient? (By the way, on a procedural note, how do I update a PEP? Do I just send an updated version to peps@python.org, or is there a better way?) Paul
On 14 Feb 2015 07:31, "Paul Moore" <p.f.moore@gmail.com> wrote:
(By the way, on a procedural note, how do I update a PEP? Do I just send an updated version to peps@python.org, or is there a better way?)
If you're happy to handle the PEP editor responsibilities described in PEP 1 yourself, you can also ask for commit access to the PEPs repo to update it directly. Cheers, Nick.
Paul _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
participants (3)
-
Ethan Furman
-
Nick Coghlan
-
Paul Moore