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
signature.asc
Description: Digital signature
