[Pythonmac-SIG] clickable Python OSX apps and os.getcwd()

[Chris Barker]

Just van Rossum wrote:
> Bugbee, Larry wrote:
 
> > Perhaps these apps should have awareness of just where they located
> > by reading a sys.whereami parameter? 

There are two problems with this:

1) "whereami" is NOT a clearly defined thing on *nix, what with
symlinks, multiple hard links, multiple file systems, etc. Frankly, I
don't quite get the details, but this was a long discussion on the
wxPython mailing list, and no one could offer a foolproof solution. THe
result is that many complex *nix applications are started with a script
that sets a few environment variables defining config directories and
the like.

2) As a rule, applications are (and should be) installed in places that
can not be written to by regular users, and config and data files should
be user-specific, so that one user does not mess with another user's
configuration.

> > I'm OK with that except for the
> > fact pgms written under Linux or Windows won't be written that way.

Programs written under Linux and Windows already have to be different
than each other in that regard. Many windows programs use the directory
that the app is in for configuration and stuff. Now that Windows is
multi-user, it really shouldn't be done that way, but old habits die
hard, and Windows is not that strict about who can write what where.

> > These pgms should run under OSX unaltered, even when BuildApplet
> > might be used to make things easier for the Mac user.

I'd like that, but it's probably not possible, unless a module that is
designed to hide these kinds of things is written/used. wxPython has a
config file abstraction, for instance. It would be a nice addition to
the standard library if you ask me.

> > As for the Dock and aliases, I would treat them as aliases.  ...but
> > where they point *is* interesting, and my candidate for the working
> > dir.

I'm not sure it's that clear that you want to use where they point.

> > Another alternative: Perhaps all this could be a specified option in
> > BuildApplet?

That is a good idea. I personally think $HOME is the only reasonable
option, but obviously  others disagree.

> > I dunno.  I just want cross platform behavior to be as much the same
> > as possible.  Is there a way?

Only with an abstraction layer.
 
> I think it's actually a reasonable feature request for BuildApplet (to
> set the working dir to the applet's containing folder). 

Yuck, yuck yuck. See above.

I'm still a little confused about whether we are talking about config
files and the like, or some other use for the "working directory", but
the arguments are similar.

The source of the problem is that the idea of a "working directory"
doesn't really make sense in a GUI environment. It is a very clear
concept in a CLI. That's why the old MacOS didn't really have such a
thing. On Windows and *nix, there is a system defined working directory,
but the concept kind of breaks down with GUI launched programs. I know
the default on Linux GUIs is to set the working directory to $HOME which
makes the most sense to me. 

I see 4 distinct uses for some kind of directory the app knows about:

1) A place to store data files, etc that the app needs. These are not
changed by or even necessarily known about by the user. In traditional
*nix, these would either be in /usr/local/mayapp/, /usr/local/var/myapp
or /usr/local/lib/myapp. It's a bit of a mess.
( NOTE: OS-vendor supplied appps use /usr rather than /usr/local ). I
guess on OS-X this would be in /Applications/myapp. I believe windows
puts this stuff in C:\Program Files\myapp

2) A place to put system global config files. These would be edited by
the system administrator, by hand, or with a GUI or whatever. These
traditionally go in /usr/local/etc/ or one of the "myapp" directories
above. On OS-X, probably also /Applications/myapp. On Windows this stuff
goes in the registry (arrgg!!!)

3) A place for user-specific config files. These traditionally go in
~/.myapp. On OS-X., probably ~/Library/Application Support. I have no
idea where these go in Windows

4) A place for the program to read and write it's working files. This is
selected by the user, in their home directory somewhere, and the default
is the working directory, which is the directory the app was started
from at the CLI, or ~/. On OS-X, I think ~/ is appropriate for a
default. On Windows this used to be c:\, now I think it tends to be
something like c:\Documents and Settings\username\My Documents. I don't
have Windows booted at the moment, sorry.

On that last one, while the old MacOS didn't really have a working
directory, most apps did start you out in the directory the app itself
lived in when you got a file:save dialog box. This resulted in a whole
lot of people storing their docs in with the app, which, while possible
on a single user system was always a Bad Idea (tm). OS-X is trying to
get away from that....

Anyway, I think the only way to have this work across platforms is to
use an abstraction layer, which could be a pretty simple roll-your-own
class for a simple app, that simply provides access to the above 4
directories.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                    		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov