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

[Mark Hammond]

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