[Python-3000] [Python-Dev] Reminder: last alphas next Wednesday 07-May-2008
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 "~/.<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?
More information about the Python-3000
mailing list