On 01:55 am, [EMAIL PROTECTED] wrote:
On Thu, May 1, 2008 at 5:03 PM, <[EMAIL PROTECTED]> wrote:
Hi everybody. I apologize for writing yet another lengthy screed about
a simple directory naming issue. I feel strongly about it but I
encourate anyone who doesn't to simply skip it.
First, some background: my strong feelings here are actually based on an
experience I had a long time ago when helping someone with some C++
programming homework. They were baffled because when I helped them the
programs compiled, but then as soon as they tried it on their own it
didn't. The issue was that I had replicated my own autotools-friendly
directory structure for them (at the time, "~/bin", "~/include",
"~/lib", "~/etc", and so on managed with GNU stow) onto their machine
and edited their shell setup to include them appropriately. But, as
soon as I was finished, they "cleaned up" the "mess" I had left behind,
and thereby removed all of their build dependencies. This was on a
shared university build server, before the days of linux as a friendly,
graphical operating system which encouraged you to look even more
frequently at your home directory, so if anything I suspect the
likelihood that this is a problem would be worse now. Since cleaning up
my own home directory, of course, I find that I appreciate the lack of
visual noise in Nautilus et. al. as well.
Also, while I obviously think all tools should work this way, I think
that Python in particular will attract an audience who is learning to
program but not necessarily savvy with arcane nuances of filesystem
layout, and it would be best if those details were abstracted.
My concern here is for the naive python developer reading installation
instructions off of a wiki and trying to get started with Twisted
development. Seeing a directory created in your home directory (or, as
the case may be, 3 directories, "bin", "lib", and "include") is a bit of
a surprise. They don't actually care where the files in their installed
library are, as long as they're "installed", and they can import them.
However, they may care that clicking on the little house icon now shows
not "Pictures", "Movies", etc, but "lib" (what's a 'lib'?) "bin" (what's
a bin? is that like a box where I throw my stuff?) "share" (I put my
stuff in "share", but it's not shared. Wait, I'm supposed to put it in
"Public"?).
Briefly, "lib" is not the only directory participating in this
convention;
you've also got the full complement of other stuff that might go into
an
installation like /usr/local. So, while "lib" might annoy me a
little, "bin
etc games include lib lib32 man sbin share src" is going to get ugly
pretty
fast, especially if this is what comes up in Finder or Nautilus or
Explorer
every time I open a window.
Unless I misread the PEP, there's only going to be a lib subdirectory.
Python packages don't put stuff in other places AFAIK.
Python packages, at the very least, frequently put stuff in "bin" (or
"scripts", I think, on Windows). Not all Python packages are pure-
Python packages either; setup.py boasts --install-platlib, --install-
headers, --install-data, and --exec-prefix options, which suggests an
"include", "bin", and "share" directory, at least. I'm sure if I had
more time to grovel around I'd find one that installed manpages.
Twisted has some, but apparently setup.py doesn't do anything with them,
we leave that to the OS packages...
Of course, very little of this is handled by the PEP. But even the
usage of the name "lib" implies that the PEP is taking some care to be
compatible with an idiom that goes beyond Python itself here, or at
least beyond simple Python packages.
Even assuming that no Python library ever wanted to install any of these
things, there are many Python libraries which are simply wrappers around
lower-level libraries, and if I want to perform a per-user install of
one of those, I am going to ./configure --prefix=~/something (and by
"something", I mean ".local" ;)) and it would be nice to have Python
living in the same space. For that matter it'd be nice to get autotools
and Ruby and PHP and Perl and Emacs (ad nauseum) all looking at ~/.local
as a mirror of /usr, so that I didn't have to write a bunch of shell
bootstrap glue to get everything to behave consistently, or learn the
new, special names for bits of configuration under "~" that are
different from the ones under /usr/local or /etc.
I replicate a consistent Python development environment with a ton of
bizarre dependencies across something like 15 different OS installations
(not to mention a bevy of virtual machines I keep around just for fun),
so I think about these issues a lot. Most of these machines are macs
and linux boxes, but I do my best on Windows too. FWIW I don't have any
idea what the right thing to do is on Windows; ".local" doesn't
particularly make sense, but neither does "lib" in that context.
There's no reasonable guess as to where to put scripts, or dependent
shared libraries... but then, per-user installation is less of an issue
on Windows.
On the Mac, the default Finder window is not your home directory but
your Desktop, which is a subdirectory thereof with a markedly public
name. In fact, OS X has a whole bunch of reserved names in your home
directory, and none of them start with a dot. The rule seems to be
that if it contains stuff that the user cares about, it doesn't start
with a dot.
Hmm. On my Mac laptop, the default Finder window is definitely my home
directory; this may be an artifact of many OS upgrades or some tweak
that I performed a long time ago and forgot about, though. Apologies if
that is not the average user experience.
For what it's worth, Ubuntu also has some directories that it creates:
Desktop, Pictures, Documents, Examples, Templates, Videos. These are
empty, and I typically delete the ones I don't use.
If it's going to be a visible directory on the
grounds that this is a Python- specific thing that is explicitly *not*
participating in a convention with other software, then please call it
"~/Python" or something.
Much better than ~/.local/ IMO.
It depends how this is being perceived. If this is Python mirroring the
/usr/local layout convention for users, as the name "lib" implies, then
this is worse. However, if Python is just trying to select a location
for its own library bookkeeping and not allow the installation of
platform libraries or scripts using this mechanism... well, ~/.python.d
would still be my preference ;-) but I could at least understand
"Python" as mirroring the Mac, GNOME and KDE convention for a few very
special directories.
Am I the only guy who finds software that insists on visible, fixed
files
in my home directory rude? vmware, for example, wants a "~/vmware"
directory, but pretty much every other application I use is nice
enough to
use dotfiles (even cedega, with a roughly-comparable-to- lib
"applications
I've installed for you" folder).
The distinction to my mind is that most dot files (with the exception
of a few like .profile or .bashrc) are not managed by most users --
the apps that manage them provide an APIs for manipulating their
contents. (Sort of like thw Windows registry.) Non-dot files are for
stuff that the user needs to be aware of.
My experience of modern Linux suggests that the usage you're describing
is gradually being phased out - applications that want to manage some
non-user-visible storage in something like the registry increasingly use
gconf (or a database, in server-land). Granted, gconf itself is stored
in dotfiles, but it's just a few.
In my home directory I have, in version control, variously written by
hand or databases maintained from externally downloaded stuff:
~/.asoundrc
~/.emacs
~/.vimrc
~/.vim
~/.Xresources
~/.fonts
~/.gnomerc
~/.inputrc
~/.bashrc
~/.bash_profile
~/.profile
~/.screenrc
~/.Xresources
~/.ssh/config
~/.ssh/authorized_keys
~/.ssh/known_hosts
I know about these dot files and I care about them and I maintain them,
but they're there for the benefit of particular pieces of software, not
me. There are a lot of other dotfiles there, but I don't think that
this set is "a few"; I am quite happy that I don't have to see every
one of them every time I am looking at my home directory in a "save as"
dialog.
I'm not sure where Python packages fall, but ISTM that this is
something a user must explicitly choose as the target of an installer.
The user is also likely to have to dig through there to remove stuff,
as Python package management doesn't have a way to remove packages.
I hope that users never have to explicitly choose this as the target of
the installer; I was under the impression that the point of adding this
feature was to allow the default behavior of distutils to work simply
and automatically on UNIX-y platforms rather than puking about
permissions, or requiring arcana like "sudo" access or editing your
shell's startup. I am quietly agitating elsewhere to get ~/.local/bin
added to $PATH by default, by the way ;-). (~/.local/lib on
$LD_LIBRARY_PATH is a hard sell, but that too...)
Once you have to know about it and explicitly choose it it's not much
more work to set all the appropriate shell environment variables
yourself. And, for that matter, *I* already have, so I suppose
regardless of the outcome of this discussion I'll still have a ~/.local
:-).
Put another way - it's trivial to make ~/.local/lib show up by
symlinking
~/lib,
That's not the same thing at all.
I'm not sure what you're saying it's not the same as. All I'm saying is
that if advanced users want to show it, they'll symlink it; if naive
users want to hide it, they'll delete it and break python, possibly
without knowing why ;).
but you can't make ~/lib disappear, and lots of software ends up
looking at ~.
But what software cares about another file there? My home directory is
mostly a switching point where I have quick access to everything I
access regularly.
Nothing's going to break, if that's what you mean. No software
processes the list of ~ and does anything with it; but lots of stuff
shows me that list. In GNOME, on Ubuntu, when a "choose file" dialog
comes up, 80% of the time it comes up by default in my home directory.
When I open a terminal it opens in my home directory. The default
location for Emacs is my home directory. I can quickly measure my
cognitive load by looking at the contents of that directory. Since my
shell starts there, autocomplete starts there, and so common-letter real
estate is scarce. I have a directory called "Projects" that I currently
autocomplete with 'p<tab>' and a directory called 'Linux' that I
autocomplete with 'l<tab>'; either public-name proposal will have me
typing an additional letter on these every day ;-).
In other words, I care about another file there. I use my home
directory as a sort of to-do list; it's mostly empty unless I have a lot
going on, in which case it fills up with various objects I'm working on,
and then I empty it out again. There are a few exceptions to this rule;
on every platform there are a few things the OS puts there, but they are
generally things like "Pictures", "Desktop", and "Music"... where I put
pictures, downloaded files, and music. The Mac's "Library" directory has
never bothered me, since it's OS-provided and basically an alternate
location for dotfiles. ("Application Data" and friends are another
story.)
In a way, I agree with you. "everything I access regularly" is a good
description of my home directory. Except, this "lib" directory is not
something I want to access regularly; very occasionally, maybe once
every few weeks, I want to chuck some dependency in there and then
forget about it for a year.
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
