On Mon, Mar 30, 2009 at 07:27:59AM +0200, RKI Andreas wrote:
>> While it is tempting to "slip in" not strictly needed improvements into
>> a bugfix it is usually - as is quite evident here - a road down which
>> dragons live.
>>
>> Don't.
>
> Well, I didn't in the first place (look at 0.3.12 package). But since
> 0.4.x it stopped working this way
Ah, indeed, I missed that - true enough, the -m was
introduced in 0.3.12 already without moving the modules. My
bad.
So, it's simply a question of getting the private modules
directory added to sys.path before gnumed.py starts up.
This *really* should be doable by at least one of
- adjust PYTHONPATH in /usr/bin/gnumed
(which I would recommend)
- use Gnumed.pth in site-packages/
(which higher wizards around here discourage us to do)
- link /usr/share/gnumed/Gnumed into site-packages/
(which is entirely non-standard and distasteful)
- modify sys.path inside gnumed.py appropriately
(which I disapprove of as it means moving
platform specific code from platform specific
layers into platform-agnostic Python code)
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
