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
Hello,
Obey Arthur Liu wrote:
> Charles Plessy a écrit :
>> Le Sat, Mar 28, 2009 at 09:48:34PM +0100, Obey Arthur Liu a écrit :
>>> Edouard Nemours a écrit :
i'd love to raise awareness of the fact that many companies and users of
debian hosts move their systems to "the cloud" (for inst
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!
>> (
Hi all,
I added the following advertisement for the proposed GSoC projects this year:
http://www.debian.org/devel/debian-med/News/2009/20090328
Feel free suggest any necessary correction.
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-med-req
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
Charles Plessy a écrit :
> Le Sat, Mar 28, 2009 at 09:48:34PM +0100, Obey Arthur Liu a écrit :
>> Edouard Nemours a écrit :
>>> Dear List,
>>>
>>> i'd love to raise awareness of the fact that many companies and users of
>>> debian hosts move their systems to "the cloud" (for instance amazon ec2).
>
Le Sat, Mar 28, 2009 at 09:48:34PM +0100, Obey Arthur Liu a écrit :
> Edouard Nemours a écrit :
> > Dear List,
> >
> > i'd love to raise awareness of the fact that many companies and users of
> > debian hosts move their systems to "the cloud" (for instance amazon ec2).
> > Recently Ubuntu started
13 matches
Mail list logo
