On Jul 20, 2009, at 4:32 AM, Antoine Pitrou wrote:
Jesse Noller <jnoller@...> 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