[Debian-med-packaging] Bug#516037: gnumed-client: hard-codes the location to python modules
Karsten.Hilbert at gmx.net
Thu Feb 19 08:47:50 UTC 2009
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
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
> import Gnumed.whatyouwant
What GNUmed currently does is:
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.
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
More information about the Debian-med-packaging