[Python-ideas] Changing the default install location, script versioning (Packages and PEP 370)

[Doug Hellmann]

On Jul 20, 2009, at 4:32 AM, Antoine Pitrou wrote:

> Jesse Noller <jnoller at ...> writes:
>>
>> The reason being, is that what if I also have python
>> 2.7 (which i do) installed, as well as python 3.1 and the
>> release-which-will-not-be-named (3.0) - if I install that same  
>> package
>> into one of the other versions, a new binary would be written with  
>> the
>> same name - a script-pythonversion might also be installed, but the
>> fact that the original script was overwritten seems broken to me.
>
> A script is a script. What version of Python it runs with shouldn't  
> be your (the
> user's) concern. Do you have two Apache binaries, one compiled with  
> gcc 3.x and
> one compiled with gcc 4.x?

That analogy doesn't hold because the compiler isn't selected at  
runtime.  The interpreter *is*, and at least with setuptools the  
script is hard-wired to run the version of the compiler used to  
install it (not just 2.6 vs. 2.7 but the actual path to the  
interpreter is embedded in the script).  So if you install one package  
with 2.6 and another with 2.7, you end up with mingled scripts but  
they (rightly) don't see the other libraries.  That's inconsistent.

>> I think the "best" fix for this is to make the bin/ directory mirror
>> the lib layout - each version would get it's own bin directory:
>>
>> .local/
>>    bin/
>>        python2.6/
>>        python3.1/
>
> -1. The point of .local/bin is that it's (supposedly) standard, so  
> that you have
> only one path to add to $PATH. Putting scripts in versioned  
> subdirectories
> totally defeats its purpose.

+1 because using versioned subdirectories lets me install apps that  
may only work under one of the versions of Python I have installed on  
my system.

Of course, a possibly better solution would be to have each app in its  
own directory with its own copy of its dependencies, but virtualenv  
makes that easy enough.

Doug