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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
