On Mon, Sep 21, 2009 at 08:36 +0100, Floris Bruynooghe wrote: > On Mon, Sep 21, 2009 at 12:35:19AM +0200, Wolodja Wentland wrote: > > On Sun, Sep 20, 2009 at 22:18 +0200, Bernd Zeimetz wrote: > > > Wolodja Wentland wrote:
>> I really don't get it. How could it possibly be better to have a
>> wild mix of programs that use '/usr/bin/python' and those using
>> '/usr/bin/env python' than having *one* predictable, consistent
>> standard enforced in the policy with *very* few exceptions. A
>> situation in which packages not using the enforced scheme are
>> considered buggy and in violation of policy and only *very* few
>> packages are granted the right to use the alternative scheme?
> This is indeed desired and the policy says to use /usr/bin/python, for
> reasons explained in this thread already. Maybe the applications
> using /usr/bin/env should get a bug filled, I agree with that.
Thank you!
> And I would even argue that /usr/bin/env is not allowed as an
> exception, the tools needing this could provide several versions of
> their app for each suppored python version, e.g. py.test, py.test2.4,
> py.test2.5.
Hmmm, no. Python applications that need a specific version of Python
should use
#!/usr/bin/env pythonX.Y
or
#!/usr/bin/pythonX.Y
stating that they need this specific version of Python. A lot of Python
software runs with different Python versions and if there are
differences the application is buggy and should get fixed.
> And if you want to use it with a non-debian environment
> you can either install the tool in that environment or set the
> environment up so you can do "/usr/local/bin/python2.6
> /usr/bin/py.test", which is no different from now.
The problem is not really the application but rather it's dependencies.
If I try to run /usr/local/bin/python2.6 /usr/bin/foo and foo depends on
module 'foo' not installed for 2.6 the application will fail. Although
it runs perfectly fine under (Debian maintained) python2.5 .
with kind regards
Wolodja
signature.asc
Description: Digital signature
