[Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008

[glyph at divmod.com]

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 "~/.<x>" 
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 "<x>" 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?