> >> That is, you're now shipping some modules in a private location > > > > This is what I understood as recommendation in #516037. > > Yes, that's recommended, but it's not a requirement. > > Anyway, you almost got it! > > >> (usr/share is > >> not in PYTHONPATH), so they are not found when you try to import them. > >> > >> You could ship Gnumed in /usr/share/gnumed/Gnumed and append > >> /usr/share/gnumed > >> to PYTHONPATH in /usr/bin/gnumed (that seems to work fine here, > > > > I tried to implement your suggestion (see last commit in SVN) but it > > does not work for me. > > You're missing a 'export' before setting the variable (or call python in > the > same line you set it).
Ah, thanks. Emilio, you are clearly a better expert on packaging Python code under Debian than me :-) > > I really wonder how this new python-support stuff > > really works. It installs *.pyc files in the same location as the > > *.py files - how can this work for different Python versions? > > Because different versions don't break the syntax (at least AFAIK), so if > your > program works with Python 2.4, it will work with 2.5 and 2.6 too. I believe Andreas was wondering about the pre-compiled pyc files being installed alongside the py files. If they are stored there they can only be precompiled by one particular Python version at a time. This made us wonder what, for example, happens if user A runs GNUmed with Python 2.5 at the same time that user B runs GNUmed with Python 2.6 on the same machine... > You don't need it, you can remove it (I've seen you've added it back). That was one of my ill-fated suggestions - it would have worked but it is clearly better if things work without it. Karsten -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
