[Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008 (original) (raw)

glyph at divmod.com glyph at divmod.com
Fri May 2 07:48:17 CEST 2008

On 03:49 am, guido at python.org wrote:

I stand corrected on a few points. You've convinced me that ~/lib/ is wrong. But I still don't like ~/.local/; not in the last place because it's not any more local than any other dot files or directories. The "symmetry" with /usr/local/ is pretty weak, and certainly won't help beginning users.

Why do you say the symmetry is weak? The name might not be that evocative, but the main thrust of what I'm saying is that "/." should be an autotools-style directory layout. The symmetry I suggest is in exactly that sense; that's what /usr/local is. I don't actually care what "" is, except I (and many others) already use "local" for that value, and the more software that honors it, the better. GNU stow (arguably the king of per-user installation management) suggests ~/local as an autotools --prefix target; the free desktop project implicitly suggests ~/.local (by suggesting ~/.local/share is a place to put the same files that would normally be searched for in /usr/share and /usr/local/share). So the word "local" is just floating around in this meme space; I don't like the word that much, but I don't see that there's a different one which more clearly evokes the concept either. I originally used "/UNIX" and then /.unix, but switched to .local when I noticed other folks doing it. One I've actually seen mentioned a few times is "/.nix-config", which I certainly don't think is any better.

It would help beginning users if ~/.local/bin and ~/.local/lib were honored by the system. I, and other adherents of this idea that it would be nice if users could install source without admin privs, have been suggesting that to distro guys when I (we) can, and I figure in a few years, somebody might bite. If that happens, it will start being easier to build stuff from source into a separated location than to need root, stomp on the system, and inevitably break some stuff. Agitating for ~/Python/Platform/Libraries on $LD_LIBRARY_PATH (or equivalent) is a lot harder to do with a straight face.

This is the reason I'm bothering to spill so many pixels on this topic; I think it would be great if Python were the first real adopter of this convention, and once one project has really gone full bore, each subsequent one is progressively easier to convince. However, if you've made up your mind on ~/Python, I think I've more than made my case at this point, so I'll stop cluttering up the lists :).

(By the way, for what it's worth: I hate the bin/lib/etc/man/src/include naming convention mess, but it's a mess which is programmatically honored in like a hundred billion lines of code. This is why I want it supported, but hidden ;).)

As a compromise, I'm okay with ~/Python/. I would like to be able to say that the user explicitly has to set an environment variable in order to benefit from this feature, just like with $PYTHONPATH and $PYTHONSTARTUP. But that might defeat the point of making this easy to use for noobs.

Is there another point? It seems to me that this change is entirely about shared conventions and "works by default" behavior. If you are going to set an environment variable, set PYTHONPATH; it's already much more flexible.

/Python opens up some new problems though, although perhaps they are trivially resolved: how should this interoperate with distutils? 'Just make "python setup.py --user" do what "python setup.py --prefix ~/.local" would do' is pretty straightforward, but "/Python" would need a new convention. Should "/Python" have a "/Python/Scripts" directory that one could add to $PATH? A "~/Python/Platform" directory, for includes, libraries, other random junk like manpages or HTML docs? ~/Python/2.6/lib, or ~/Python2.6/lib?

To be fair, a separate, and purpose-designed Python directory layout might also make certain things neater. For example one could support parallel installation with Python2.6 (or Python/2.6) by giving each a 'lib' and 'bin' directory, and always having the scripts in the 2.6/bin dir invoke the 2.6 interpreter, rather than having separated space for libraries but having to mangle the names of scripts ("twistd8.0-py2.6"). I'd still prefer compatibility-by-convention with other tools, languages, etc, though. In the long term, if everyone followed suit on ~/.local, that would be great. But I don't want a ~/Python, ~/Java, ~/Ruby, ~/PHP, ~/Perl, ~/OCaml and ~/Erlang and a $PATH as long as my arm just so I can run a few applications without system-installing them.

On OS X I think we should put this somewhere under ~/Library/. Just put it in a different place than where the Python framework puts its stuff.

Isn't the whole point that it should be the same place? Under current Python releases, OS X already has this functionality via ~/Library/Python/2.5/site-packages.

Also, I'd strongly suggest supporting both ~/Library (although the existing location seems fine to me) and whatever the default is on other platforms; there are already enough points of pain where OS X behaves "kind of like a UNIX, but not really", and every project needs to add these little workarounds and caveats in the documentation. Is there a benefit to be derived from making this situation worse by introducing another such subtlety?

More information about the Python-Dev mailing list