On Sun, Jul 19, 2009 at 6:57 PM, Jesse Noller<jnoller@gmail.com> wrote:
So, I've finally been able to kick my python 2.5 boat anchor, and I'm now relishing in the delightful future of 2.6. Two things struck me though, digging into PEP 370's (per user site-packages) behavior.
The first is this - when you install a package (say, pip) into the .local directory via the --user command, the package ends up in the correct lib directory; but the binary get dropped into ./local/bin - this seems wrong. 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.
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/ lib/ python2.6/ python3.1/
Of course, doing this begs the question - why have /bin and /lib be top-level directories, instead favoring a layout which looks like:
.local/ python2.6/ bin/ lib/
The data and doc directories which some packages might include should follow the same convention, to avoid conflicts in those directories as well.
In addition to what you've mentioned here and in your blog post, the ~/.local directory is not well thought out when it comes to binary extension modules and It ignores the needs for multi-architecture systems that do not use fat binaries such as all x86_64 Linux/BSD/Solaris systems. It also ignores the fact that ~ may be shared across machines which are not the same architecture. Compiled modules .so, .dll, .whateveryouroses need to live in a subdirectory below the pythonX.Y directory unique to the OS + architecture they were compiled for. Even that still won't be perfect for shared home directories as it doesn't take into account which OS distro version (read: external shared library dependencies) an extension was compiled for but its a good start: .local/ python2.6/ linux-x86_64/ linux-i386/ linux-mipsel/ darwin-fatmultiarchbinaryorwhateverapplecallsthem/ darwin-x86_64/ netbsd-ppc/
The second behavior is more of a "man I wish for a unicorn" type of thing - I think that --user should be removed, and by removed, I mean made the default action when "python setup.py install" is invoked. Users should need to instead pass in a --global flag to alter the behavior to install into the system's site-packages and bin directories. The reason is simple - installation to the global site is typically a super-user task, and can side-effect all users, it's growing into more of a no-no as more OS vendors grow to rely on the packaged/included versions of python.
+10 - Unicorns for everyone! The system python belongs to the OS and should -never- be touched by anything that isn't the OSs own package management system. People violate this all the time. That is the path to the dark side. Doing that on any system I'm near leads to anger. Anger leads to hate. Hate leads to suffering and revocation of root privileges. -gps