On Thu, Jul 09, 2009 at 13:08 +0200, Andrea Gasparini wrote:
> Hi,
> I'm searching for some pointers of discussions about python shebang.
> My main consideration is that if I want to install another python
> installation or another interpreter (say for example jython,
> ironpython, or
> unladenswallow ... ) I can't use it for all python programs, because
> every
> update of python will rewrite /usr/bin/python.
I would like to raise this topic again because I think that it should be
decided upon.
The current python-policy contains a "do what you seem fit, but we
*prefer* /usr/bin/python" policy regarding "/usr/bin/python" vs
"/usr/bin/env python". This is not acceptable because it renders the
behaviour of Python programs totally unpredictable *if* the Python
environment is changed.
Statistics
==========
I can not generate an overview over all python applications, but the
following numbers give an overview on the schemes employed on *my*
system:
Programs in /usr/bin
--------------------
#!/usr/bin/env python 43 programs
#!/usr/bin/env python2.4 1 program
#!/usr/bin/env python2.4 2 programs
#!/usr/bin/python 50 programs
#!/usr/bin/python2.4 1 program
#!/usr/bin/python2.5 4 programs
As you can see the policy lead to a wild potpourri of shebang schemes
used for python packages.
Discussion
==========
I want to propose a policy change which enforces the usage of either
"/usr/bin/python{X.Y}" *or* "/usr/bin/env python{X.Y}" and MBF against all
packages that do not comply with the new policy. I believe that deciding
upon one scheme is much better than the situation right now. There will
be arguments against and in favour of both, so go forth and discuss. ;-)
I recently filed #547003 [1] but feel that it is not a bug as long as
the policy is not clear on the subject. Depending on the outcome of this
discussion i will either tag it with the tag used to monitor this policy
transition or "wontfix".
The bug report however is a perfect example for the problems users run
into with the current scheme. "Recent" developments within the python
developers community like virtualenv [2] will lead to many very
differently configured Python environments being present on a Debian
system. This is a development Debian will have to face in the future, so
let's get squeeze ready for it.
I use virtualenv extensively to test my software against different
python and library versions and am always wondering if an particular
/usr/bin/* program will work within that environment or use the standard
one.
Note that i am arguing as a Python *developer*, the situation for
*users* of Python software might be different.
#!/usr/bin/env python{X.Y}
--------------------------
I prefer if "#!/usr/bin/env python" would become the default policy
- except for a few packages that *have* to run within the Python
environment distributed with Debian - for the following reasons:
1. It works as expected if the administrator just installs the current
Python environment distributed with Debian.
2. Python developers and users making use of virtualenv can expect
programs installed with aptitude to work regardless of whether they
are within a virtualenv or not.
Programs that modify the Python environment (easy_install, pip, ...)
use the currently used Python environment, which is IMHO the expected
behaviour.
If a virtual environment is initialised with "--no-site-packages" the
user explicitly states that packages present in the Python environment
used to set up the virtual environment should not be used, and will
have to take care of missing libraries. The breaking of dependencies
is wanted and expected in this case and this should be the only case
in which breakage occurs.
3. If an administrator decides to install an additional Python
environment from source into /usr/local it is *their* responsibility
and stated goal to administer a Python environment not supported by
Debian and the breakage that might occur is *their* responsibility.
Final Remarks
-------------
Please note that IANDD and am therefore not aware of the intricacies
associated with distributing Python within Debian. I am sure I
overlooked plenty of arguments and problems of either policy, but I
think that deciding upon *one* scheme is much better than the situation
we have right now.
If the Debian community decides to go with "#!/usr/bin/python{X.Y}" I am
left in a situation where the tools I am working with do not behave in
the way *I* expect them to. Is there a way to automatically patch every
Python program to use the scheme preferred by me unless it contains a
"no no" flag set by the package maintainer?
with kind regards
Wolodja Wentland
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=547003
[2] http://pypi.python.org/pypi/virtualenv
Attachment:
signature.asc
Description: Digital signature