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

[Mark Hammond]

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:

* I'm referring to *external* tools that launch Python.  They obviously 
need to know where the binaries are to launch them.  Eg, the PEP397 
launcher; the (admittedly few) people who use the launcher would need to 
upgrade it to work under your scheme.  Ditto *all* other such tools that 
locate and launch Python.

* "most code" isn't a high enough bar.  If we only considered such 
anecdotes, most backwards compatibility concerns would be moot.

> 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