[Python-Dev] PEP 405 (Python Virtual Environments) and Windows script support
Vinay Sajip
vinay_sajip at yahoo.co.uk
Mon May 28 19:25:10 CEST 2012
In the recent check-in I made of the PEP 405 functionality, there is a Windows
executable. Antoine asked what this was in his comment on the checkin, but I
couldn't respond via Gmane (my usual method) as for some reason his post
doesn't appear there.
PEP 397 (Python launcher for Windows) has not yet been accepted, so there still
needs to be some way of natively launching scripts in Windows which is
equivalent to /path/to/venv/bin/foo. The way setuptools (and hence Distribute)
does this is to shadow each script with an executable: whereas a script foo
would be simply placed in /path/to/venv/bin/ on POSIX, on Windows, the files
foo.exe and foo-script.py (or foo-script.pyw) are placed in
\path\to\venv\Scripts. The user can run \path\to\venv\Scripts\foo just as on
POSIX.
The foo.exe file is just a copy of a stock launcher executable which finds its
name from the C argv[0], and based in that name (foo in this case), invokes
foo-script.py or foo-script.pyw with the appropriate Python interpreter.
There are two versions of the launcher - console and Windows - built from the
same source. These append -script.py and -script.pyw respectively, hard-coded
into the executable. The idea is for packaging to do the appropriate copying of
stock-launcher.exe to foo.exe when installing scripts. AFAIK this is not yet in
packaging, but I implemented it in the pythonv branch (that code was not part
of the PEP 405 implementation - it just allowed me to explore how venvs would
work with packaging on Windows).
The setuptools versions of these scripts are compiled using MinGW. I don't know
if we can use them as is, and as the functionality is fairly simple, I
implemented it in a separate project using MSVC:
https://bitbucket.org/vinay.sajip/simple_launcher
We may not need any of this, if PEP 397 is accepted in time. However, if it
isn't, I would expect that something like these launchers will be needed.
In my packaging code in the pythonv branch, there are different variants -
t32.exe, t64.exe, w32.exe, w64.exe - one of which is picked as the source for
copying to the destination when installing a script. These .exes are
UPX-compressed versions of the executables created by the Microsoft compiler
and linker (using static linking).
Comments welcome, especially on whether Windows users agree that something like
this is needed in the absence of PEP 397 in Python 3.3.
Regards,
Vinay Sajip
More information about the Python-Dev
mailing list