On Sun, Sep 20, 2009 at 22:18 +0200, Bernd Zeimetz wrote:
> Wolodja Wentland wrote:
[ placed on top because this is the main point ]
> > 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.
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?
As I said in the last reply to Piotr's mail: I don't insist on making
'/usr/bin/env python' the default scheme and if you thought that this
was the intention of raising this discussion you must have misunderstood
me/my mails. (or more likely: I failed to convey my point)
I said many times that I lack the experience to see all aspects
associated with packaging Python for Debian which is why I discuss the
topic with people that do that on a daily basis. I just had the impression
that it is a good idea to have *one* scheme used by programs in Debian.
Could you please enumerate the "large" issues associated with
'/usr/bin/env python' for me? If the issues are that large why are
programs that use '/usr/bin/env python' not (considered) completely
broken?
I just had the, maybe naïve, impression that enforcing '/usr/bin/env
python' has some advantages while still providing the same
user/maintainer experience if *only* the Debian packaged Python is
installed. This would for example allow users of python-virtualenv as
packaged by Debian to run programs installed with apt* while they are in
their virtual environment and not having to install all these programs
*again* with a package management solution from Python (preferrably
pip).
This is use case 1 as described below.
It still won't break if other Python versions are installed
in a way sanctioned by Debian, by making sure that "python" always
refers to the one shipped with Debian.
The only problem I see here is that people will have programs in their
$PATH that *might* not be executable because there is a mismatch between
$PATH and $PYTHONPATH. I don't have a solution for that, but this is
clearly outside of the "supported by Debian" realm.
> > 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 already do, which is actually the reason why I raised this topic here,
because I saw incoherent and unpredictable behaviour of programs that i
execute while being in the virtual environment.
The problem is that *some* programs I execute while being in the
environment work with the Python interpreter installed within the virtual
environment (copy of /usr/bin/python in .virtualenvs/foo/bin) while
others use /usr/bin/python. This is inconsistent behaviour which forces
the user to constantly check if the program they want to run uses
'/usr/bin/python' or '/usr/bin/env python'.
I have basically two use cases:
1. Install not yet packaged software into a virtual environment so i
can use it without polluting the system environment. The virtual
environment is initially a clone of the system one.
2. Create virtual environments with not yet packaged Python versions
(2.6, 3.1) in order to test software with new and upcoming Python
versions.
For 2. I install the Python environment in /usr/local, delete
/usr/local/bin/python (so that if i type python I *always* get the
system /usr/python/bin one and create virtual environments by executing
python{2.6,3.1} (mk)virtualenv.
If the standard policy is changed to '/usr/bin/python' i will just
install another version of python in /usr/local which matches the one
installed by Debian and basically re-create the system environment so
*I* can be sure that if I run software in the used environment all
programs will work with that environment.
Your statement "Just use ..." seems to imply that the creation of
virtual environments for Python versions not yet shipped by Debian is
possible without installing the respective Python version to /usr/local
first. Could you tell me how?
> > 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.
Exactly!
> > 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.
OK, that is true. I can't really provide a solution for that right now
(if there is one) but let me say that it is quite likely (so not
certain!) that if the user runs reportbug that reportbug itself is
executed within the very same Python environment the bug is reported on.
But let's not discuss this now as it has nothing to do with the
intention of this thread (-> at the beginning of this mail/thread).
with kind regards
Wolodja Wentland
Attachment:
signature.asc
Description: Digital signature