On 29 Nov, 11:49 pm, [EMAIL PROTECTED] wrote:
>On Nov 29, 2006, at 5:18 AM, [EMAIL PROTECTED] 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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
