[Python-Dev] Python install layout and the PATH on win32 (original) (raw)

Mark Hammond skippy.hammond at gmail.com
Fri Mar 16 00:19:50 CET 2012

On 16/03/2012 8:57 AM, VanL wrote:

On 3/14/2012 6:30 PM, Mark Hammond wrote:

So why not just standardize on that new layout for virtualenvs? That sounds like the worst of all worlds - keep all the existing special cases, and add one.

I'm not so sure. My concern is that this will break external tools that attempt to locate the python executable from an installed directory. However, I'm not sure this requirement exists for virtual environments - such tools probably will not attempt to locate the executable in a virtual env as there is no standard place for a virtual env to live.

So having a standard layout in the virtual envs still seems a win - we keep the inconsistency in the layout of the "installed" Python, but tools which work with virtualenvs still get a standardized layout.

[At least I think that is your proposal - can you confirm that the directory layouts in your proposal exactly match the directory layouts in virtual envs on all other platforms? ie, that inconsistencies like the python{py_version_short} suffix will not remain?]

Just to be completely clear, my current concern is only with the location of the executable in an installed Python.

The fact is that most code doesn't know about this, only installers or virtual environments. Most code just assumes that distutils does its thing correctly and that binaries are installed... wherever the binaries go.

Of course - but this raises 2 points:

Again, I have experience with this, as I have edited my own install to do this for a couple of years. The breakage is minimal and it makes things much more consistent and easier to use for cross-platform development.

All due respect, but I'm not sure that is a large enough sample to draw any conclusions from. I've offered 2 concrete examples of things that will break and I haven't looked for others.

Also, I'm still yet to see what exactly becomes "easier" in your model? As you mention, most Python code will not care; distutils and other parts of the stdlib will "do the right thing" - and indeed, already do for Windows. So the proposal wants to change distutils and other parts of the stdlib even though "most code" won't notice. But the code that will notice will be broken!

So I dispute it is "easier" for anyone; I agree it is more consistent, but given the certainty external tools will break, I refer to you the Zen of Python's thoughts on consistency ;)

Right now we are in front of the knee on major 3.x adoption - I would like to have things be standardized going forth everywhere.

It is a shame this wasn't done as part of py3k in the first place. But I assume you would be looking at Python 3.4 for this, right? So if people start working with Python 3.3 now and finds this change in 3.4, we are still asking them to take the burden of supporting the multiple locations. I guess I'd be less concerned if we managed to get it into 3.3 and also recommended to people that they should ignore 3.2 and earlier when porting their tools/libraries to 3.x.

I think I've made all the points I can make in this discussion. As I mentioned at the start, I'm not quite -1 on the idea, so I'm not going to push this barrow any further (although I'm obviously happy to clarify anything I've said...)

Cheers,

Mark

More information about the Python-Dev mailing list