[Python-Dev] PEP 405 (Python Virtual Environments) and Windows script support (original) (raw)

Mark Hammond skippy.hammond at gmail.com
Tue May 29 02:04:20 CEST 2012

Vinay originally wrote:

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.

I don't understand the relationship between this "stock launcher" and the PEP 397 launcher. They seem to have quite distinct requirements without much overlap. Specifically, I'm not aware that the current PEP 397 implementation could perform the same role as the "stock launcher" - IIUC, it has no special handling of the "-script" suffix or special logic based around its argv[0].

So unless I'm mistaken, even with PEP 397 accepted, either this "stock launcher" is still necessary anyway or the PEP398 launcher would need the addition of new features so it could replace the stock launcher.

FWIW, Vinay and I exchanged some private mail recently about how to best integrate the PEP397 launcher with virtualenvs - and while we both agreed it would be nice, we couldn't come up with anything worthwhile. Having the launcher be aware of a virtualenv when invoked via file associations is problematic - for example, Windows Explorer is unlikely to have a virtualenv configured in its environment. Even when considering just command-line usage there are some edge-cases that make things problematic (eg, what if a script in a venv nominates a specific Python version via a shebang line? What if a venv is activated but the user/launcher attempts to execute a script outside the venv? etc.)

On 29/05/2012 9:24 AM, Nick Coghlan wrote: ...

It would have been better if the issue of script management on Windows had been raised in PEP 405 itself - I likely would have declared PEP 397 a dependency before accepting it (even if that meant the feature missed the alpha 4 deadline and first appeared in beta 1, or potentially even missed 3.3 altogether).

However, I'm not going to withdraw the acceptance of the PEP over this - while I would have made a different decision at the time given the additional information (due to the general preference to treat Windows as a first class deployment target), I think reversing my decision now would make the situation worse rather than better. That means the important question is what needs to happen before beta 1 at the end of June. As I see it, we have two ways forward: 1. My preferred option: bring PEP 397 up to scratch as a specification for the behaviour of the Python launcher (perhaps with Vinay stepping up as a co-author to help Mark if need be), find a BDFL delegate (MvL? Brian Curtin?) and submit that PEP for acceptance within the next few weeks. The updated PEP 397 should include an explanation of exactly how it will help with the correct implementation of PEP 405 on Windows (this may involve making the launcher pyvenv aware).

As above, it isn't clear to me how the additional complexity and list of caveats in real use make it worthwhile to have the PEP397 launcher pyvenv aware.

2. The fallback option: remove the currently checked in build artifacts from source control and incorporate them into the normal Windows build processes (both the main VS 2010 process, and at least the now-legacy VS 2008 process)

For alpha 4, I suggest going with MvL's suggestion - drop the binaries from Mercurial and accept that this aspect of PEP 405 simply won't work on Windows until the first beta.

Agreed - ISTM that this stock launcher is probably going to need to co-exist with the PEP397 launcher for the long term.

Cheers,

Mark

More information about the Python-Dev mailing list