On Sun, Sep 20, 2009 at 23:49 +0200, Piotr Ożarowski wrote:
> [Wolodja Wentland, 2009-09-20]
> > On Sun, Sep 20, 2009 at 20:52 +0200, Piotr Ożarowski wrote:
> >>[Wolodja Wentland, 2009-09-20]
> >>> 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*.
> > > If user/administrator is not following FHS and touching files outside
> > > /usr/local, it's his problem. /usr/local and /etc is where administrator
> > > can do his changes/improvements.
> > I completely agree! Did I give you reason to believe that I actually
> > propose such insane actions?
> See above. Sane administrator will never change /usr/bin/python symlink.
> (too many tools depend on it)
Yes! Did you interpreted what I said differently? I gave that example to
exemplify in "a somewhat extreme example" which I consider to "be
stupid" (to actually do) what I consider *supported* actions taken by an
administrator and what actions are *unsupported* . The example is
clearly considered unsupported as is installing additional python
versions.
> > Which is why I try to avoid setuptools
> setuptools it not bad per se, it's just how people use it
Hmm, i had the impression after reading:
http://www.b-list.org/weblog/2008/dec/14/packaging/
that distutils is preferred over setuptools. And that package maintainer
have a lot of work to get application data out of the egg, making sure
that a (Python) package is installed with
"--single-version-externally-managed", patching code to work without
relying on setuptools application data disceovery API and and and ...
> > as hard as I can and use plain distutils to package my software and
> > urge users to install them to PREFIX /usr/local or use
> > --install-layout=deb.
>
> --install-layout=deb should be used by package maintainers only, if
> you're encouraging users to install files in /usr and not /usr/local
> (--install-layout=deb is just a shortcut for --prefix=/usr and
> --install-lib=/usr/lib/pythonX.Y/dist-packages) you're doing exactly the
> same what "sudo easy_install"-people do (it doesn't matter that these
> modules were not installed via Eggs)
I *should* have added " ... if they *insist* on installing to /usr",
sorry that i forgot to do so. I encourage to install to /usr/local or to
use a virtual environment.
> > I don't see how this is related to the intention of my original post
> > which was the *suggestion* for a policy change to require *either*
> > '/usr/bin/python' or '/usr/bin/env python' so that Python programs
> > installed with apt* show consistent behaviour.
> There's no "either". No permanent changes system wide, never!
What do you mean by "permanent changes system wide"?
> Some applications can be used in local env.[0] and some cannot. These
> that can be used in such env. should have '/usr/bin/env python' in
> shebang, these that cannot - '/usr/bin/python*'.
> [0] by local env. I mean something like python-virtualenv, not changing
The problem is that, IPython for example, does not work with
python-virtualenv right now. Which is why i filed a bug and thought:
* "What else will not work?"
* "Wouldn't enforcing */env python on all packages mean that all
packages work with python-virtualenv?"
* "Wouldn't that make python programs on Debian much more
predictable, because they all (except few) follow the same
scheme?"
* "Is this *really* a good idea?"
* "Let's discuss this on debian-python"
and I wrote my initial mail (which you might want to read again) ...
> `env python` output system wide or replacing /usr/bin/python
> symlink. No one except python package maintainer can change
> /usr/bin/python*
Yes, exactly! Never said anything else. I you take this from the
"extreme" example let me say that users/admins also have the freedom to
delete their harddrive or throw their computer out of the window. Which
just like violating the FHS cause in effects *unsupported* by Debian and
would be just as stupid and insane.
> > And to reiterate another point: If I as a user change my Python
> > environment is it unreasonable to assume that all Python software will
> > run in that environment?
> you can try to run in this new env. whatever application you want, even
> packaged one with shebang set to /usr/bin/python* (see one of my
> previous mails to see how), most of them will fail, though.
This is just not true. Only (some) packages with '/usr/bin/python' will
fail because the virtual environment will initially be an almost (see
below) exact clone of the original environment used to create the
virtual environment. It will even use the same modules and not copy it
to the new environment. (Or did *I* completely misunderstood the way
virtualenv works? (possible))
It *only* true iff (note the two 'f') the user creates an virtual
environment with '--no-site-packages' which is done deliberately and
with the *explicitly stated goal* to accept breakage of software that
relies on libraries in $PYTHONPATH but which is still present in $PATH.
.. which is IMHO acceptable.
I am arguing mainly as a developer who cares about Debian being a great
platform for software development in Python (which it is!) and Python
applications with '/usr/bin/python' force me to install every single
application I would like to use into every single virtual environment
if i want to use the applications in them. This also forces me to use
Python package managers (pip) to install that software and means I might
miss some nice patches from Debian not yet incorporated into upstream.
This essentially renders python-virtualenv unusable with the system
environment and somehow renders the python-virtualenv package
meaningless, because it would be much easier to just create the
virtual environment with /usr/local/bin/python and not having to worry
about "contamination" of the environment with modules installed system
wide. The issue that i'll still have broken applications in my $PATH
remains but that's OK with me because I'll know that I have to install
all applications that i would like to use into the virtualenvironment
again.
If my expectations are wrong I sincerely apologise for taking so much of
your time (for which I am *very* grateful) it's just that I would like
to point out things that stand in my way when developing Python on
Debian.
with kind regards
Wolodja Wentland
with kind regards
Wolodja Wentland
Attachment:
signature.asc
Description: Digital signature