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

[Mark Hammond]

On 15/03/2012 3:03 AM, Lindberg, Van wrote:
> On 3/14/2012 1:32 AM, Mark Hammond wrote:
>> 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.
>
> A built tree would look the same as always - the directories would only
> be moved (if at all) during installation. Thus, you will still be able
> to run python directly from a built installation.

So long as the location of the "lib" dir doesn't change, that is 
probably true.  If lib was to change though, then PC/getpathp.c would 
need to change which is where my concern came from.

>>> 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
>
> If you look at these projects, though, they *special case* Windows to
> account for the different layout. Removing this difference will allow
> these projects to remove their special-casing code.

I don't think that is true.  One of the examples I offered was a .bat 
file - it wouldn't be possible to remove the .bat file with your 
proposal.  The other example was the Windows specific launcher.

Most things that need to locate the Python executable aren't actually 
Python code - once Python is running, locating the executable is as 
simple as sys.executable.  So by their very nature, tools needing to 
locate Python will tend to be platform specific in the first place.

Can you offer any examples of 3rd party tools which could unify code in 
this scheme, and particularly, where this scheme would cause them to 
have less code, not more?

>> - 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 actually reinforces my point:
>
> First, this code would actually still work. The section ":FoundPython"
> sets the PATH to "%VIRTUAL_ENV%\bin;%PYTHONINSTALL%;%PATH%" (L80), which
> would still allow python.exe to be found and run.
>
> Second, look at that line again. Mozilla actually has edited this code
> so that the jetpack uses a cross-platform "bin" convention, just as I am
> proposing.

I think you misunderstand the .bat file - there is no python executable 
in the bin directory.  The bat file is locating your already installed 
Python and attempting to use it.

> Third, one element of this proposal is that there would be a key placed
> in the registry that points directly to the location of the python
> executable, making locating it trivial to locate programmatically on
> Windows.

That sounds reasonable, but it still causes breakage, and still causes 
extra code for tools needing to support earlier versions.  Saying "hey, 
it's easy to fix" are just words to someone frustrated trying to get 
things working with a later version of Python.

Don't get me wrong - the scheme you propose is how it should have been 
done in the first place, no question.  My issue is the breakage this 
will cause versus the benefit.

My other questions still remain: who specifically will benefit from 
this, and what would be the cost to those beneficiaries of sticking with 
the existing scheme?  The only benefit I've seen suggested is 
aesthetics, and while that is laudable, I don't think it is enough to 
justify breakage.

Cheers,

Mark