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 01:13:59PM +0200, Alexander Reichle-Schmehl wrote:
>
> Colleagues are busy; uploaded ;)
Cheers :)
--
Jonathan Wiltshire
PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52
signature.asc
Description: Digital signature
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
Dear mentors,
Piotr is unable to sponsor rednotebook at the moment, so I'm seeking a
sponsor for the new version until he's back online.
It's a new upstream version only, no packaging changes, and targets
unstable.
The dsc is on mentors at
http://mentors.debian.net/debian/pool/main/r/rednotebook
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
13 matches
Mail list logo
