On Mon, Mar 30, 2009 at 03:27:55PM +0200, Josselin Mouette wrote:
> I also tend to prefer solutions that look more robust, for example
> against existing PYTHONPATH variables. The rest is a matter of taste.
This is (now) the relevant part in /usr/bin/gnumed:
# packages which install the GNUmed
Le lundi 30 mars 2009 à 14:50 +0200, Karsten Hilbert a écrit :
> On Mon, Mar 30, 2009 at 02:18:31PM +0200, Josselin Mouette wrote:
>
> > > - modify sys.path inside gnumed.py appropriately
> > > (which I disapprove of as it means moving
> > >platform specific code from platform specific
> > >
On Mon, Mar 30, 2009 at 02:18:31PM +0200, Josselin Mouette wrote:
> > - 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)
>
> This one is my fa
Le lundi 30 mars 2009 à 12:26 +0200, Karsten Hilbert a écrit :
> - use Gnumed.pth in site-packages/
> (which higher wizards around here discourage us to do)
Please don’t! This completely defeats the point of shipping packages in
a private directory.
> - link /usr/share/gnumed/Gnumed into si
Le lundi 30 mars 2009 à 12:18 +0200, Karsten Hilbert a écrit :
> For what it's worth the gnumed.py outermost Python script sayeth:
>
> #!/usr/bin/env python
>
> and, then, even that is ignored because the /usr/bin/gnumed
> shell script calls gnumed.py via "python -m".
Which means using the defau
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 packa
On Mon, Mar 30, 2009 at 10:54:31AM +0200, Josselin Mouette wrote:
> However the document you read makes it clear that it is better,
> for python applications, to put the (private) modules in a private
> location. Both installation schemes have been available for a long time,
> and this issue is or
Le dimanche 29 mars 2009 à 20:46 +0200, Karsten Hilbert a écrit :
> 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 wh
On Mon, 30 Mar 2009, Emilio Pozuelo Monfort wrote:
I think pysupport does this for you. When the default interpreter changes, it
will regenerate all the .pyc files for the new one.
This lets me relax a bit more, but hmmm, I'm not fully convinced ...
And FWIW I've just noticed that your dh_py
Andreas Tille wrote:
> On Sat, 28 Mar 2009, Emilio Pozuelo Monfort wrote:
>
>> I got an
>> error that mx.DateTime can't be imported, so you probably need to
>> depend on
>> python-egenix-mxdatetime).
>
> Thanks to Emilio I was able to fix the gnumed-client package which was
> in fact
> lacking th
Andreas Tille wrote:
> On Sun, 29 Mar 2009, Emilio Pozuelo Monfort wrote:
>
>> In that case the .pyc files won't be loaded, but the .py ones, I guess
>> (please
>> somebody correct me if I'm wrong). Nothing to worry about as people
>> will usually
>> be using the default interpreter.
>
> I admit
On Sat, 28 Mar 2009, Emilio Pozuelo Monfort wrote:
I got an
error that mx.DateTime can't be imported, so you probably need to depend on
python-egenix-mxdatetime).
Thanks to Emilio I was able to fix the gnumed-client package which was in fact
lacking the python-egenix-mxdatetime build dependenc
On Sun, 29 Mar 2009, Emilio Pozuelo Monfort wrote:
In that case the .pyc files won't be loaded, but the .py ones, I guess (please
somebody correct me if I'm wrong). Nothing to worry about as people will usually
be using the default interpreter.
I admit I really prefered the former behaviour of
On Sun, 29 Mar 2009, Emilio Pozuelo Monfort wrote:
You're missing a 'export' before setting the variable (or call python in the
same line you set it).
Uhm - stupid me. That's a beginners fault ... :-(
In the first releases of gnumed-client package I used Gnumed.pth but
dropped this since I
On Sun, 29 Mar 2009, Karsten Hilbert wrote:
-
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 ma
On Sun, 29 Mar 2009, Karsten Hilbert wrote:
Well, you are trying to solve two things at once:
1) make the "python -m" calling convention work
2) move GNUmed modules to a private location
While, yes, this WAS recommended in that report I tried furiously
to argue against doing both at once becau
Karsten Hilbert wrote:
>> 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 :-)
That was shell ;)
>>> I really wonder how this new pyth
> >> 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 y
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!
>> (
For what it's worth here is my concluding suggestion in that bug thread:
-
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
> > That is, you're now shipping some modules in a private location
>
> This is what I understood as recommendation in #516037.
Well, you are trying to solve two things at once:
1) make the "python -m" calling convention work
2) move GNUmed modules to a private location
While, yes, this WAS rec
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.
(usr/share is
not in PYTHONPATH), so they are not found when you try to import them.
You could ship Gnumed in /usr/share
Hi Andreas,
Andreas Tille wrote:
> Hi,
>
> I tried to implement the Python policy [1] using python-support to
> the new GNUmed packages but failed. If I try the basic essence
> of the /usr/bin/gnumed script I get:
>
> $ python -m Gnumed.wxpython.gnumed
> Traceback (most recent call last):
> F
Hi,
I tried to implement the Python policy [1] using python-support to
the new GNUmed packages but failed. If I try the basic essence
of the /usr/bin/gnumed script I get:
$ python -m Gnumed.wxpython.gnumed
Traceback (most recent call last):
File "/usr/lib/python2.5/runpy.py", line 85, in run_
24 matches
Mail list logo
