[Python-3000] Namespaces are one honking great idea -- let's do more of those!

[Mike Meyer]

On Tue, 05 Feb 2008 08:20:00 +0900 "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
> Mike Meyer writes:
>  > On Mon, 04 Feb 2008 20:22:04 +0900 "Stephen J. Turnbull" <stephen at xemacs.org> 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

The python link is part of the python install on every system I've
dealt with - including from the source tarballs - as they all install
it, and the vast majority of software that needs python to run expect
to find it there.

>  > > so nothing "breaks" when the user uses #!/usr/bin/python3.0.
>  > Unless, of course, the user used their systems packaging software
> 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.

[...]

>  > *and* as installed by most packaging systems.
> Different issue.  That *is* a packaging system's prerogative IMO.

Right. And the packaging system is what most people deal with in the
real world. Ignoring the real world is a good way to become
irrelevant. And while we can't control them (GNU/Linux packagers have
a really nasty habit of installing software configured in ways the
author doesn't want to support), we can at least nudge them in the
right direction by making it easy to do things in what we consider to
be the best way.

>  > > 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).

So you want the default behavior after installing python to be that
the "python" command not be found? So that people who see software
that "needs python" will grab and install python, and then have the
software not work because they it no longer installs that link by
default? Or do you expect everyone who installs python software to fix
the executables to refer to the version of python they have installed?
Or maybe just install every version some software author was using
when they wrote the software?

>  > 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.

If the users are using a packaging system, then what setup.py does -
or does not do - is largely irrelevant. Users will get what the
packagers want them to have, and there's not jack that the people
actually writing the software can do about it.

If the users get what setup.py provides, then they built from source,
so they at least know how to install and deal with a build
environment, and it's reasonable to assume that they may know a little
bit more than that.

We can either determine a good way to deal with the issues this
raises, and nudge package builders and people doing installs from
source in that direction by making those things the default, or at
least easy; or we can do what was done in the 1->2 transition and let
them all work it out for themselves, and risk once again having some
popular distro on which "python" is obsolete for the next N years.

    <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.