On Sun, Sep 20, 2009 at 19:05 +0200, Piotr Ożarowski wrote:
> [Wolodja Wentland, 2009-09-20]
> > On Sun, Sep 20, 2009 at 18:42 +0200, Piotr Ożarowski wrote:
> > > IMHO /usr/bin/python should be a rule and "/usr/bin/env python" - (very
> > > rare) exception (ipython or paster might qualify here)
> >
> > Could you elaborate on the reasons for that? I am really interested and
> > it is my impression that enforcing the "/usr/bin/env python" scheme
> > provides significant advantages over "/usr/bin/python".
>
> I tested my package(s) with specific interpreter, if administrator/user
> wants to use different one, he can run "his_own_python /usr/bin/application",
> I will not fix bugs reported by users/administrators who use custom
> interpreter. "/usr/bin/env python" might be a good solution for local
> scripts but not for system ones.
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.
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.
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 ...
To give a somewhat extreme example. A user could decide to install a new
Python version within /usr/local - which i think is commonly done with
Python 2.6 these days - and could link /usr/bin/python to
/usr/local/bin/python2.6 . Which would - of course - be stupid but the
administrator has the freedom to do so and has to live with the
consequences, ie errors in the execution of programs installed with
apt*.
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.
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.
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.
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!
I don't want to stress this point though. I am happy with more or less
anything the Debian python team decides upon as long as the policy
enforces *one* scheme, so I as a user know exactly how Python
application distributed by Debian behave. This would mean a MBF against
all packages that break that scheme, which might mean a lot of little
fixes to existing packages but at least ensures consistency. If I can do
anything to help with that I am happy to do so, although I think
applying a patch is more work than just changing existing quilt/dpatch
directly.
with kind regards
Wolodja Wentland
Attachment:
signature.asc
Description: Digital signature