Wolodja Wentland wrote:
> I can see your need as a python application maintainer to be *sure* that
> the python version distributed with debian is used to run that program.
Exactly.
> But the '/usr/bin/env python' scheme will result in exactly that
> behaviour if the administrator/user has not intentionally installed a
> *unsupported* Python environment.
If the behaviour is the same, why use '/usr/bin/env python' then. If the
admin/user/fool wants to install a different python version, they're able to
modify/reinstall the application in a sane way, and probably under the new
Python environment (which is the only proper way, mixing stuff likes to break
things).
>
> I always had the impression that Debian relies on the fact that users
> install software via the package manegment system provided by Debian,
> but are still given the freedom to make adjustments to their environment
> for which they take full responsibilty. IMHO installing a new Python
> environment not provided (and supported) by Debian falls into this
> freedom. But this comes with responsibility ...
Exactly. You're not forced to install something via apt. There is /usr/local and
$PATH.So if you install a new Python environment, please install all the
necessary stuff for it on your own. Thats the only way that makes sense for a
distribution, otherwise there is absolutely no sane way to react on bug reports
and other issues.
> [..]
> To alleviate this problem a little Debian could give precise
> instructions on how to install external Python environments. Which would
> for example mean, that if a user installs Python 2.6 / 3.1 / whatever
> she will delete /usr/local/bin python and can use the new version by
> explicitly calling python{2.6,3.1}. If this is done '/usr/bin/env
> python' still runs the program with the standard Debian version.
Just use http://pypi.python.org/pypi/virtualenv
> I am aware of the fact that this might cause a lot of bug reports by
> users who don't know what they are doing, and expect their system to
> "just work" whatever stupid decisions they take as an administrator.
Something which should be avoided clearly.
> This could be solved by providing feedback to the user that they are
> using a unsupported Python version whenever they try to report a bug
> with reportbug and it is found that '/usr/bin/env python' is indeed not
> the Python environment as distributed by Debian.
Which will only work as long as reportbug is run in the same environment... and
which will probably just fail again, as reportbug is using Python.
> If however the *env python scheme is enforced in the policy the problems
> I outlined in my original post are solved without additional problems
> (?). If there are any i would like to know about them!
There are probably not more problems than the few which were mentioned already,
but they are such large issues that thinking about enforcing the use ov env is
absolutely insane.
--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
