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

[Karsten Hilbert]

> > > 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.
> 
> There is nothing specific in using a private modules directory.

Currently there is one hardcoded value in a wrapper shell script,
namely the path to gnumed.py (which, as you point out, can be
overcome by "python -m ..."). Everything else just works off the
standard modules locations in a standard Python install.

How is using "/usr/share/gnumed-client/" not specific to Linux ?
It wouldn't work on Windows or on a Mac. Now, of course,
one could install some logic in, say, gnumed.py to adjust
sys.path (which is discouraged) according to the platform
(which is then hardcoding more than one path and also deeper
inside the code layers). And this *still* leaves
the question which way to abolish the hardcoding of finding
gnumed.py in the first place.

My suggestion would be:

- call gnumed.py with the python -m ... option if that works
  - this would rid us of that hardcoded path - a great thing

- leave modules where they are and GNUmed finds them by default
  - if the Debian package maintainers want to put packages
    elsewhere, fine, as long as the rest of the code finds
    them by default - I am just adverse to including more
    detection logic for no good reason that I can see

> > 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.
> 
> I fail to see any difference between doing it in shell or in python.
If I do it in the python code I'll have to include logic
to differentiate the platform.

If it is done in the shell script I don't -- because the shell
script will not run on Windows anyway. Windows will run *another*
script, namely a batch file or who-knows-what. gnumed.py doesn't
care. It simply assumes it runs in a sane environment. That is my point,
not whether it can be done or not.

Karsten
-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01