On Tue, 31 Mar 2009, Karsten Hilbert wrote:
Which then would beg the initial question on how this works
if two people use the same .py files simultaneously with two
different Python versions if the .pyc files end up in the
same directory...
They do not as I explained and so this question is vo
On Tue, Mar 31, 2009 at 09:30:21AM +0200, Hilbert, Sebastian wrote:
> Am Montag 30 März 2009 14:20:08 schrieb Karsten Hilbert:
> > On Mon, Mar 30, 2009 at 02:16:23PM +0200, Josselin Mouette wrote:
> > > If she does, this should work in both cases, but when running it for a
> > > non-default versio
Am Dienstag 31 März 2009 09:50:07 schrieb Andreas Tille:
> On Tue, 31 Mar 2009, Sebastian Hilbert wrote:
> > If I am not mistaken it will recompile the pyc file and will be slower
> > only for the first time.
>
> No. As user (who is calling the program) you are not allowed to write to
> /usr/share
On Tue, 31 Mar 2009, Sebastian Hilbert wrote:
If I am not mistaken it will recompile the pyc file and will be slower only
for the first time.
No. As user (who is calling the program) you are not allowed to write to
/usr/share/*. This this can not happen.
Kind regards
Andreas.
--
h
Am Montag 30 März 2009 14:20:08 schrieb Karsten Hilbert:
> On Mon, Mar 30, 2009 at 02:16:23PM +0200, Josselin Mouette wrote:
> > If she does, this should work in both cases, but when running it for a
> > non-default version, startup will be much slower because the .pyc files
> > won’t be used.
>
>
On Mon, Mar 30, 2009 at 02:16:23PM +0200, Josselin Mouette wrote:
> If she does, this should work in both cases, but when running it for a
> non-default version, startup will be much slower because the .pyc files
> won’t be used.
OK, that's the crux of the matter and answers the question:
It'll w
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, 30 Mar 2009, Karsten Hilbert wrote:
BTW, you did see we released 0.4.2, did you ? It should be
a drop-in over 0.4.x as usual.
;-)
You can always check
http://svn.debian.org/wsvn/debian-med/trunk/packages/gnumed-client/trunk/debian/changelog?op=file&rev=0&sc=0
to learn whether I'
On Mon, Mar 30, 2009 at 01:00:52PM +0200, RKI Andreas wrote:
> It's done in SVN - just want to test this evening whether everything works
> like expected than I will upload.
Great. I'll be testing as soon as it hits unstable.
BTW, you did see we released 0.4.2, did you ? It should be
a drop-in
On Mon, 30 Mar 2009, Karsten Hilbert wrote:
- adjust PYTHONPATH in /usr/bin/gnumed
(which I would recommend)
It's done in SVN - just want to test this evening whether everything works
like expected than I will upload.
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNS
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 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 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_
28 matches
Mail list logo
