[Python-Dev] Python and the Linux Standard Base (LSB)

[glyph at divmod.com]

On 29 Nov, 11:49 pm, barry at python.org wrote:

>On Nov 29, 2006, at 5:18 AM, glyph at divmod.com wrote:

>> I'd suggest using "~/.local/lib/pythonX.X/site-packages" for the
>> "official" UNIX installation location, ...

>+1 from me also for the concept.  I'm not sure I like ~/.local though
>- -- it seems counter to the app-specific dot-file approach old
>schoolers like me are used to.  OTOH, if that's a convention being
>promoted by GNOME and other frameworks, then I don't have too much
>objection.

Thanks.  I just had a look at the code in Combinator which sets this up and it turns out it's horribly inconsistent and buggy.  It doesn't really work on any platform other than Linux.  I'll try to clean it up in the next few days so it can serve as an example.

GNOME et. al. aren't promoting the concept too hard.  It's just the first convention I came across.  (Pardon the lack of references here, but it's very hard to google for "~/.local" - I just know that I was looking for a convention when I wrote combinator, and this is the one I found.)

The major advantage ~/.local has for *nix systems is the ability to have a parallel *bin* directory, which provides the user one location to set their $PATH to, so that installed scripts work as expected, rather than having to edit a bunch of .foorc files to add to your environment with each additional package.  After all, what's the point of a per-user "install" if the software isn't actually installed in any meaningful way, and you have to manually edit your shell startup scripts, log out and log in again anyway?  Another nice feature there is that it uses a pre-existing layout convention (bin lib share etc ...) rather than attempting to build a new one, so the only thing that has to change about the package installation is the root.

Finally, I know there are quite a few Python developers out there already using Combinator, so at least there it's an established convention :).

>I also think that setuptools has the potential to be a big
>improvement here because it's much easier to install and use egg
>files than it is to get distutils to DTRT with setup.py.  (I still
>detest the command name 'easy_install' but hey that's still fixable
>right? :).  What might be nice would be to build a little more
>infrastructure into Python to support eggs, by say adding a default
>PEP 302 style importer that knows how to search for eggs in
>'nests' (a directory containing a bunch of eggs).

One of the things that combinator hacks is where distutils thinks it should install to - when *I* type "python setup.py install" nothing tries to insert itself into system directories (those are for Ubuntu, not me) - ~/.local is the *default* install location.  I haven't managed to make this feature work with eggs yet, but I haven't done a lot of work with setuptools.

On the "easy_install" naming front, how about "layegg"?

>What if then that importer were general enough (...)

These all sound like interesting ideas, but they're starting to get pretty far afield - I wish I had more time to share ideas about packaging, but I know too well that I'm not going to be able to back them up with any implementation effort.

I'd really like Python to use the ~/.local/bin / ~/.local/lib convention for installing packages, though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20061130/82573734/attachment.html