<html><body>On 29 Nov, 11:49 pm, barry@python.org wrote:<br /><br />&gt;On Nov 29, 2006, at 5:18 AM, glyph@divmod.com wrote:<br /><br />&gt;&gt; I'd suggest using "~/.local/lib/pythonX.X/site-packages" for the<br />&gt;&gt; "official" UNIX installation location, ...<br /><br />&gt;+1 from me also for the concept. &#160;I'm not sure I like ~/.local though<br />&gt;- -- it seems counter to the app-specific dot-file approach old<br />&gt;schoolers like me are used to. &#160;OTOH, if that's a convention being<br />&gt;promoted by GNOME and other frameworks, then I don't have too much<br />&gt;objection.<br /><br />Thanks. &#160;I just had a look at the code in Combinator which sets this up and it turns out it's horribly inconsistent and buggy. &#160;It doesn't really work on any platform other than Linux. &#160;I'll try to clean it up in the next few days so it can serve as an example.<br /><br />GNOME et. al. aren't promoting the concept too hard. &#160;It's just the first convention I came across. &#160;(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.)<br /><br />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. &#160;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? &#160;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.<br /><br />Finally, I know there are quite a few Python developers out there already using Combinator, so at least there it's an established convention :).<br /><br />&gt;I also think that setuptools has the potential to be a big<br />&gt;improvement here because it's much easier to install and use egg<br />&gt;files than it is to get distutils to DTRT with setup.py. &#160;(I still<br />&gt;detest the command name 'easy_install' but hey that's still fixable<br />&gt;right? :). &#160;What might be nice would be to build a little more<br />&gt;infrastructure into Python to support eggs, by say adding a default<br />&gt;PEP 302 style importer that knows how to search for eggs in<br />&gt;'nests' (a directory containing a bunch of eggs).<br /><br />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. &#160;I haven't managed to make this feature work with eggs yet, but I haven't done a lot of work with setuptools.<br /><br />On the "easy_install" naming front, how about "layegg"?<br /><br />&gt;What if then that importer were general enough (...)<br /><br />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.<br /><br />I'd really like Python to use the ~/.local/bin / ~/.local/lib convention for installing packages, though.</body></html>