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 orthogonal to the bug I initially reported.
Exactly.
> If GNUmed uses #!/usr/bin/python as a shebang, it will not be possible
> to run it with two different Python versions on the same machine. Only
> the default one applies. If the default version changes, all .pyc files
> will be regenerated and they will still work fine.
>
> If GNUmed uses #!/usr/bin/python2.X as a shebang, only one version will
> be available at all times. In this case you should always call
> "dh_pysupport -V2.X" so that it knows for which Python version these
> files are.
But it does neither by your suggestion ! :-)
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".
Now, one user might one day say
python2.5 -m Gnumed.wxpython.gnumed
while another one might go
python2.6 -m Gnumed.wxpython.gnumed
What happens in that case ?
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
