Per user dirs on Non-Unix platforms (was Re: [Python-Dev] Where to install non-code files)

[Peter Funk]

> [Fred]
> >   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 
	<http://www.python.org/pipermail/pythonmac-sig/2000-May/003667.html>
) 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
this situation.

Only the first kind of event should be solved for all platforms:  
<FANTASY>
    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?
</FANTASY>

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
idiom 
	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)
 
def getgraildir():
    return getenv("GRAILDIR") or os.path.join(gethome(), ".grail")    
----- snip ------
def gethome():
    try:
        home = getenv("HOME")
        if not home:
            import pwd
            user = getenv("USER") or getenv("LOGNAME")
            if not user:
                pwent = pwd.getpwuid(os.getuid())
            else:
                pwent = pwd.getpwnam(user)
            home = pwent[6]
        return home
    except (KeyError, ImportError):
        return os.curdir
---------------- 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?

Regards, Peter
-- 
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)