Per user dirs on Non-Unix platforms (was Re: [Python-Dev] Where to install non-code files)
Tue, 30 May 2000 18:37:41 +0200 (MEST)
> > Now that this idea has fermented for a few days, I'm inclined to not
> > like it. It smells of making Unix-centric interface to something that
> > isn't terribly portable as a concept.
Yes. After thinking more carefully and after a closer look to what
Jack Jansen finally figured out for MacOS (see
) I agree with Fred. My initial idea to put something into
'os.environ["HOME"]' on those platforms was too simple minded.
> > Perhaps there should be a function that does the "right thing",
> > extracting os.environ["HOME"] if defined, and taking an alternate approach
> > (os.getcwd() or whatever) otherwise.
Every serious (non trivial) application usually contains something like
"user preferences" or other state information, which should --if possible--
survive the following kind of events:
1. An upgrade of the application to a newer version. This is
often accomplished by removing the directory tree, in which this
application lives and replacing it by unpacking or installing
in archive containing the new version of the application.
2. Another colleague uses the application on the same computer and
modifies settings to fit his personal taste.
On several versions of WinXX and on MacOS prior to release 9.X (and due
to stability problems with the multiuser capabilities even in MacOS 9)
the second kind of event seems to be rather unimportant to the users
of these platforms, since the OSes are considered as "single user"
systems anyway. Or in other words: the users are already used to
Only the first kind of event should be solved for all platforms:
Imagine you are using grail version 4.61 on a daily basis for WWW
browsing and one day you decide to install the nifty upgrade
grail 4.73 on your computer running WinXX or MacOS X.Y
and after doing so you just discover that all your carefully
sorted bookmarks are gone! That wouldn't be nice?
I see some similarities here to the standard library module 'tempfile',
which supplies (or at least it tries ;-) to) a cross-platform portable
strategy for all applications which have to store temporary data.
My intentation was to have simple a cross-platform portable API to store
and retrieve such user specific state information (examples: the bookmarks
of a Web browser, themes, color settings, fonts... other GUI settings,
and so... you get the picture). On unices applications usually use the
os.path.join(os.environ.get("HOME", "."), ".dotfoobar")
or something similar.
Do people remember 'grail'? I've just stolen the following code snippets
from 'grail0.6/grailbase/utils.py' just to demonstrate, that this is still
a very common programming problem:
---------------- snip ---------------------
# XXX Unix specific stuff
# XXX (Actually it limps along just fine for Macintosh, too)
return getenv("GRAILDIR") or os.path.join(gethome(), ".grail")
----- snip ------
home = getenv("HOME")
if not home:
user = getenv("USER") or getenv("LOGNAME")
if not user:
pwent = pwd.getpwuid(os.getuid())
pwent = pwd.getpwnam(user)
home = pwent
except (KeyError, ImportError):
---------------- snap ---------------------
[Guido van Rossum]:
> I could see defining a new API, e.g. os.gethomedir(), but that doesn't
> help all the programs that currently use $HOME... Perhaps we could do
> both? (I.e. add os.gethomedir() *and* set $HOME.)
I'm not sure whether this is really generic enough for the OS module.
May be we should introduce a new small standard library module called
'userprefs' or some such? A programmer with a MacOS or WinXX background
will probably not know what to do with 'os.gethomedir()'.
However for the time being this module would only contain one simple
function returning a directory pathname, which is guaranteed to exist
and to survive a deinstallation of an application. May be introducing
a new module is overkill? What do you think?
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260
office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)