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

[Stephen J. Turnbull]

Mike Meyer writes:
 > 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:
 > >  > 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.

And your point might be?  Did you snip the part where I explained that
that is irrelevant to my point before reading it?  If not, please
explain; I've already explained (better expressed as "setup.py
installdefault", see below) how I propose that practical issue be
dealt with both sanely and compatibly.

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

GNUbies *will* ignore you.  "GNU maintainers" do not care, by
Stallman's definition, about the "right way" for any system but the
GNU System.  Unfortunately, there is no such thing as The GNU System,
so each packager feels free to define what's right for the GNU System
in terms of their own practices.  This is paradigmatic for why
"python3" is a nonsolution.

To paraphrase the good Samuel Clemens, I think the reports of
impending Python irrelvancy are vastly overblown.  As my friend Tom
Lord puts it, the vast majority of software doesn't exist yet.  The
battleground for relevancy lies in the future.

Finally, I have been arguing that the right way is precisely to leave
it up to the packagers because they have the knowledge and the
technology to deal with dependencies.  Python (the project) does not.
As Nick Coghlan put it, "you're pushing for a language level solution
to a system level problem: how do we reliably associate files with an
application that understands them?"

 > So you want the default behavior after installing python to be that
 > the "python" command not be found?

Maybe.  It wouldn't be hard to detect that there is no "python" on
$PATH and finish either the configuration stage or the install stage
with the warning,

    **** There is no 'python' on $PATH. ****
    If you want this version of Python to become your default "python",
    run "setup.py installdefault" now.
    (You may need Administrator or root privileges to do so.)

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

No.  If the user is root installing Python as support for system
software, then what setup.py does can mess up the packaging system,
and this is the most likely result of having "python" and/or "python2"
and/or "python3" links made by default.

OTOH, if they're installing into a non-system location, the text above
is more than sufficient warning to those with the ability and courage
to successfully run "setup.py install" from tarballs.

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

That's exactly what I just wrote.  I don't understand why you draw the
conclusion you do, that a "python3" link somehow becomes a good idea
(rather than a crock pandering to lazy developers downstream).

 > We can either determine a good way to deal with the issues this
 > raises,

Nick's point, and my point, is that all the good ways require either
downstream developer discipline in use of shebangs that are adequate,
or system-level support.

 > and nudge package builders and people doing installs from
 > source in that direction by making those things the default, or at
 > least easy;

Although we disagree on what the semantics should be, what could be
easier than "setup.py installdefault", and still retain some semblance
of providing minimal opportunity for exercise of responsibility by the
sysadmin?

 > or we can do what was done in the 1->2 transition and let
 > them all work it out for themselves,

The whole problem is that the RightThang[tm] has nothing to do with
Python package builders and people who install Python from source.
The problem is entirely downstream from Python: it is that app
developers target a specific feature set but are unwilling to make the
miniscule effort to announce it with a properly specific shebang.

If in fact the Python 2.x for x in 0, ..., 6 are nearly always
backward compatible, then a better way (but still not perfect) for the
system or user to solve the problem is for the system to create a
"python2.y" alias for python2.x, for y in 0, ..., x-1.  If you detect
a bug (eg, the one that came in with the introduction of boolean
True), then you can simply override the alias with an installation of
the needed version.  *This doesn't work with "python2" shebangs.*  You
must also fix the app's shebangs.  If you upgrade the app, you must
remember to fix the shebangs again.  ("Remember" includes maintaining
local and vendor branches in a SCM of course.)

 > and risk once again having some popular distro on which "python" is
 > obsolete for the next N years.

Huh?  Python 1.5.2 was then, and remains now, a better language for my
purposes than any version of awk, FORTRAN, or Perl I've ever used. :-)

I only wrote about 10 Python scripts on Red Hat systems, but none of
them barfed because "python" was "obsolete."  Red Hat had *lots* of
other problems, which is why I abandoned it.  Having to type
"python2.2" occasionally was the least of my complaints about RHL
(which I have been pronouncing "are hell" since the last millennium: I
was shocked, SHOCKED, I tell you, when they chose to make that
pronunciation the official name of their flagship certified product!)