Re: Experimental Python packages
On Thu, 6 Sep 2001, Neil Schemenauer wrote:
> Bruce Sass wrote:
> > The python-base package gives me python->python2.1, from Python-2.1.1.
> > What happens when I point python to python3.0, will pydoc still work.
>
> What happens when I point /usr/bin/perl to Perl 4? I think I've just
> screwed up the system pretty badly. Use /usr/local for site specific
> customizations. Don't screw with /usr/bin/python.
but it would probably work with Python (so far ;)
I use local/bin for trying out stuff on an experimental basis,
/usr/bin for those experiments that seem to work...
> > Why should Debian decide that bin/python _must_be_ a specific version
> > of Python when it is so simple to specify which python a executable
> > needs. "Gratuitous" is the only word I can think of that accurately
> > describes behaviour like that.
>
> What's wrong with /usr/local/bin/python?
Nothing, if that happens to point to the interpreter you want to use.
> > Pydoc is part of Python, so there should be no problem explicitly
> > specifying which Python that is (it is not limiting in any way).
> >
> > The experimental py-2.1 packages have:
> >
> > 1) #/usr/bin/env python2
> >
> > it should be:
> >
> > 2) #/usr/bin/env python2.1
>
> No, it should be:
>
> #!/usr/bin/python2.1
>
> You can't use /usr/bin/env. What happens if someone installs python2.1
> somewhere else in the path and that version does not have the modules
> that the script needs?
Someone changing the default python<ver> (the one in /usr/bin) is
likely to know what they are getting into... it is a question of how
many and which hoops.
> You should use "#!/usr/bin/env python" for
> scripts that you write or locally install scripts. That way you can
> change /usr/local/bin/python to point to a newer version of Python and
> everything starts using that new version.
...I use ".../env python", and play with local/bin/python while
experimenting. /usr/bin/python->whatever I'm working with most (no
problems so far), local/bin/python only exists when I forget to
delete it.
I don't really have a problem with #!/usr/bin/python2.1, it ensures
that all of Debian's stuff will work; I would prefer "env python2.1",
so I can use whatever tweaked 2.1 I happen to be playing with by
controlling symlinks in local/bin instead of in /usr/bin.
> > you (Neil) want:
> >
> > 3) #/usr/bin/python
> >
> > I like 2) because it lets me have a /usr/local/bin/python2.1
> > overshadow the packaged 2.1 if I want, simply by fiddling with
> > symlinks in /usr/local/bin. If every executable did that I could
> > point python to whatever I wanted and things just work.
>
> Things would not work. Things would break. How do we assure that the
> locally installed Python is compatible with all the installed Python
> packages?
What a user installs is not Debian's concern, you just gotta assume
they know what they are doing; making it easy for users to do what
they want should be Debian's concern (imo)... arbitrarily declaring
that python is Python-? interfers with that.
> > ...where has my thinking failed?
>
> For some reason you insist on being able to change /usr/bin/python. If
> you give up on that everything is simple and works fine.
Well, ya, because I can't see any reason for not allowing it to be
whatever Python. I also don't believe everything will work fine.
One of the first comments I made when Gregor brought the subject up
was, `different versions of Python can co-exist peacefully, the
problem seems to be rotating the different versions through the same
package name'. No one disputed that, and the discussion eventually
turned to how to achieve the "peaceful" bit (emacsen like, brute
force?)... you seem to be going backwards, and I expect that whatever
problems you solve will need to be tackled again next release.
I think the tougher approach is only tougher in the short term (a
release or two), the simple approach is tougher in the long run.
- Bruce
Reply to: