[Debian-med-packaging] Bug#516037: gnumed-client: hard-codes the location to python modules

[Karsten Hilbert]

On Thu, Feb 19, 2009 at 09:34:15AM +0100, Josselin Mouette wrote:

> I don’t have one handy, but the idea is to consider it a regular script.
> 
> Looking more closely at gnumed.py, it occurs to me that it is not even
> meant to be in a modules directory:
>         if __name__ != "__main__":
>                 print "GNUmed startup: This is not intended to be imported as a module 
>
> This way, instead of a wrapper script, you could directly put this
> script in /usr/bin,
You could. But if you do it *instead* you lose the added
value of the wrapper script which is to source local shell
fragments before GNUmed starts if they exist.

> adding to it the necessary logic to read the
> configuration.
There IS NO logic to read configuration in gnumed(.sh). All
there is is a (double) check for the systemwide config file
which may not even be mandatory anymore.

> This is very simple, just ship the modules to /usr/share/gnumed-client,
> and modify your script to do something like:
>         import sys
>         sys.path.append("/usr/share/gnumed-client")
>         import Gnumed.whatyouwant

What GNUmed currently does is:

	import Gnumed.whatyouwant

and expect to *just find* its modules in sys.path - which is
AFAICT the right thing to do and works cross platform. This
runs on all flavours of Linux plus Windows plus MacOSX so
I'm not going to hardcode *something else* right into my
Python scripts which is specific to Linux or even Debian.

No, if something is hardcoded or dynamically adjusted it
should really be in an OS-level wrapper around gnumed.py
such as a shell script.

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