Re: [Help] Failed to apply new Python policy to GNUmed packages
> >> 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
Reply to: