[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Help] Failed to apply new Python policy to GNUmed packages



Hiya,

Andreas Tille wrote:
> On Sat, 28 Mar 2009, Emilio Pozuelo Monfort wrote:
> 
>> 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).

>  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.

That's not the case with Python 3 though.

You don't need to install it for every supported Python version, that's only
done by public modules and extensions.

> In the first releases of gnumed-client package I used Gnumed.pth but
> dropped this since I used python-support (version 0.3.x).  Does this
> mean I might use this again?

You don't need it, you can remove it (I've seen you've added it back).

Cheers,
Emilio

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: