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

[Gregory P. Smith]

On Sun, Jul 19, 2009 at 6:57 PM, Jesse Noller<jnoller at 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