Re: [Gnumed-devel] appPath - os.environ(GNUMED)

[Karsten Hilbert]

> can be hard-wired, as on Linux we can find it in two guesses:
> /usr/share/gnumed and /usr/local/share/gnumed. 
That's what I was gonna say.

According to Andreas Tille who has experience with packaging
things for Debian and who wants to provide gnumed.debs our
"binary" stuff should live below /usr/share/gnumed/ (btw,
/usr/local/share/ kind of defeats it's own purpose ... why
would I want to share what is local and thus has the notion of
being private to this machine ?

I'd suggest the following approach as it is always useful to
test for available features rather than platform and assume
the availability of a feature on that platform (someone might
just want to install gnumed into a Cygwin environment where in
fact one does have /usr/share/):

Do hardcoded os.path.exist()s on
/usr/share/gnumed/[our_module_dirs] and if all of them fail
assume that we are on a platform that does not have this dir
structure and read os.environment(GNUMED) (further tests may be
added inbetween those assumptions).

> Particularly on Windows the
> argv[0] trick does not work.
Arrrgh !!! Are you sure of that ? I've been pulling this off
in Pascal for ages (yes, I did parse the PSP for that :-)

I do need to get my win test machine up and running. At least
I have the metal lying around now.

> However argv[0] is useful for developers so
> that that client runs irrespective of its location.
Hm. How about asking developers to symlink /usr/share/gnumed/
to the appropriate place in their CVS tree ? Or - since this
would hamper their ability to do a clean _install_ of gnumed
in parallel to the CVS tree - require them to set GNUMED=adir
even on Linux ? This seems cleaner to me. Or maybe the other
way round (as you almost do already): first test for explicit
setting of GNUMED, then fall back to /usr/share/gnumed and
then fail. This would allow parallel installation and CVS as
well as flexible control over what version (CVS or install)
gets executed. That's probably it, or is there a thinko left
somewhere ?

> Is there a better solution? Can we ask the Python interpreter, whre is
> this csript file?
Hm, not a bad though. It should know what file it is currently
running. But it need not necessarily resolve symlinks which,
again, leaves us with inconsistent results. Guess, the approach
outlined above is the safest.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346