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
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
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
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!
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
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 python-support
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
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
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
9 matches
Mail list logo
