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
