Python 3.3 includes PEP 397, a Python launcher for Windows, and PEP 405, virtual environment support in core. Unfortunately the Windows launcher does not respect virtual environments. Even with with a virtual environment activated and the current directory at the virtual environment's root, the Windows launcher will start python with the system environment, not the active virtual environment.


To demo:

Install python 3.3 for windows.

Create a virtual environment:

  C:\>c:\Python33\Tools\Scripts\pyvenv.py c:\virtpy

Activate the virtual environment:

  C:\>virtpy\Scripts\activate.bat
  (virtpy) C:\>

Optionally cd to the virtual environment:

  (virtpy) C:\>cd virtpy
  (virtpy) C:\virtpy>

Start Python 3 with the new windows launcher:

  (virtpy) C:\virtpy>py -3
  Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit (Intel)] on win32
  Type "help", "copyright", "credits" or "license" for more information.
  >>>

Check sys.path

  >>> import sys
  >>>
  >>> sys.path
  ['', 'C:\\Windows\\system32\\python33.zip', 'C:\\bin\\Python33\\DLLs', 'C:\\bin\\Python33\\lib', 'C:\\bin\\Python33', 'C:\\bin\\Python33\\lib\\site-packages']
  >>>


The worst effect I've found is that installation of a package with windows launcher, "py -3 setup.py install", will ignore the active virtual environment and will change the system Python environment. That's bad because users frequently employ virtual environments to isolate changes that could damage a system configuration.

When using an activated virtual environment, there is no need to use "py" - just use "python". Primarily, the launcher looks for a shebang line in a script to determine which interpreter to use for the script. If no shebang line can be found, it will launch "the default" Python, which is currently the most recent Python 2.x found in the registry. When invoked via py -3 (or with suitable settings in the configuration), it will use the most recent Python 3.x found in the registry. Since venv interpreters are not in the registry, they will never be invoked as the default Python. However, any scripts installed into venvs will have the correct shebang lines, so they will launch with the venv's interpreter.

I don't believe this is a bug, as the system is IMO working as designed and as per PEP 397. If the launcher is asked to launch a script which contains a shebang, while a venv is activated, it will run with the interpreter indicated by the shebang, rather than the venv's interpreter.

Perhaps one could consider an enhancement whereby if no shebang is found, a different approach is used to find the interpreter - e.g. looking for "python" on the path before looking in the registry to locate an interpreter. The question arises as to whether this should be tied to a specific condition such as the presence of an environment key PYLAUNCHER_USEPATH. (This is of course orthogonal to whether or not a venv is activated, but would have the desired effect when a venv is activated, without needing to tie the launcher to a virtualenv-specific environment value such as VIRTUAL_ENV.)

Issue titled "Python Launcher and virtualenv?" at https://bitbucket.org/vinay.sajip/pylauncher/issue/15/ is related.

Recent changes to the launcher mean that for a shebang line of "#!/usr/bin/env python", the path is searched for a Python executable. This will include the Python executable in an activated venv, so I am closing this issue. The change is already available for testing in the standalone launcher at

https://bitbucket.org/pypa/pylauncher/downloads/

and should be incorporated into the launcher released with Python 3.4.

@Vinay
Is there any discussion which lead to this change?

> Is there any discussion which lead to this change?

http://mail.python.org/pipermail/python-dev/2013-May/125939.html