Mike Meyer writes: > On Mon, 04 Feb 2008 20:22:04 +0900 "Stephen J. Turnbull" <[EMAIL PROTECTED]> > wrote: > > Marcin ___Qrczak___ Kowalczyk writes: > > > Dnia 03-02-2008, N o godzinie 10:24 +0900, Stephen J. Turnbull pisze: > > > > I don't see any need to shorten "python3.0" to "python3". > > > There is a need. Using #!/usr/bin/python3.0 would break as soon as > > > python3.1 is released, while #!/usr/bin/python3 would be fine, at > > > least in the next few years. > > First of all, under current policy, installing Python 3.1 would not > > uninstall or overwrite Python 3.0 > > Wrong. The recommend "make install" overwrites the "python" link.
Irrelevant. That "python" link is *not involved* in the shebang quoted above, and it is not part of any Python installation, precisely because it is designed (nowadays) to point to a real installed python somewhere else. (What I mean is that even though setup.py does make one, that doesn't mean that version of Python has any ownership rights to it.) > > so nothing "breaks" when the user uses #!/usr/bin/python3.0. > > Unless, of course, the user used their systems packaging software > to upgrade the default python install, and that's been moved to the > newer version. In that case, every packaging system I've ever used > will remove the old version, Making that decision is the distro's prerogative, nay, its sacred duty. But here, we're discussing what Python should do, not what distros should do. > > On the contrary, Python 3.1 itself may be buggy. I do not think is > > it appropriate for the Python installer to make that decision for > > the user by creating a link to the most recent python3.x. > > Except it currently does, both during the install from source Then altinstall should be made the default. > *and* as installed by most packaging systems. Different issue. That *is* a packaging system's prerogative IMO. > > What I see no need for is a policy statement *by Python* that there > > "should" be a "python3" link, or which python3.x is should point to. > > So do you think we should do away with the "python" link as well? Yes. The decision to have one should be made by the user or the distro. This doesn't mean that Python shouldn't provide an install target that makes one, but it should require more typing than the default install (and thus an explicit decision). > The reason OS distributions are hard on "rogue" users who change the > meaning of "python" is because their system tools quit working when > you do that, as they all use "python". No, it's a more general policy. That is an important justification in the case of python, but the tools generally do blow up if users mess with other "virtualized" files, too, because the metadata is incorrect. > Having the python install provide the major version link as well as > the versionless "python" link means it becomes reasonable to > distribute scripts that use link, because most installs will have > it. It encourages vendors to use that link in their system-specific > scripts, so they can provide a backwards-incompatible version of > python, and make "python" invoke it for users. Both of these are good > things. Sure, both are good things. But having setup.py provide them is not. If the user and/or the distro is providing the link, setup.py should assume that they know what they are doing. "How can setup.py know that?" you ask. Yes, *that is precisely the problem.* setup.py doesn't and can't know whether the user, the distro, or a previous avatar of setup.py created that link. Odds are very good that the distro knows far more about what the user wants than the user does (ie, it knows the dependency graph in detail, and the user just wants that graph satisfied), but setup.py does not know. And should not know. That's the distro's job. _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
