[Python-Dev] Python install layout and the PATH on win32

[Mark Hammond]

On 14/03/2012 6:43 AM, VanL wrote:
> Following up on conversations at PyCon, I want to bring up one of my
> personal hobby horses for change in 3.3: Fix install layout on Windows,
> with a side order of making the PATH work better.
>
> Short version:
>
> 1) The layout for the python root directory for all platforms should be
> as follows:
>
> stdlib = {base/userbase}/lib/python{py_version_short}
> platstdlib = {base/userbase}/lib/python{py_version_short}
> purelib = {base/userbase}/lib/python{py_version_short}/site-packages
> platlib = {base/userbase}/lib/python{py_version_short}/site-packages
 > include = {base/userbase}/include/python{py_version_short}

As per comments later in the thread, I'm -1 on including 
"python{py_version_short}" in the lib directories for a number of 
reasons; one further reason not outlined is that it would potentially 
make running Python directly from a built tree difficult.  For the same 
reason, I'm also -1 on having that in the include dir.

> scripts = {base/userbase}/bin

We should note that this may cause pain for a number of projects - I've 
seen quite a few projects that already assume "Scripts" on Windows - eg, 
virtualenv and setuptools IIRC - and also assume the executable is where 
it currently lives - one example off the top of my head is the mozilla 
"jetpack" project - see:

https://github.com/mozilla/addon-sdk/blob/master/bin/activate.bat#L117

This code (and any other code looking in "Scripts" on Windows) will fail 
and need to be updated with this change.  Further, assuming such 
projects want to target multiple Python versions, it will need to keep 
the old code and check the new location.

Another bit of code which would be impacted is the PEP397 launcher; it 
too would have to grow version specific logic to locate the executable.

So while I'm not (yet) -1 on the general idea, I'm close.  I guess I 
don't understand how the benefits this offers outweigh the costs to 3rd 
parties.  Given the work on making Python more virtualenv friendly, 
can't we just wear the costs of the existing scheme in the stdlib and 
avoid breaking the code already out there?  IOW, who exactly will 
benefit from this, and how does the cost of them supporting the existing 
scheme compare to the cost of the breakage to multiple 3rd parties?

Mark