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

[Mike Meyer]

On Wed, 06 Feb 2008 10:32:53 +0900 "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
> 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

It's not irrelevant, because you're basic assumption is wrong. Or
maybe you're just engaged in wishful thinking. The default python
install includes the python link, and overwrites, much as you might
wish it otherwise.

> To paraphrase the good Samuel Clemens, I think the reports of
> impending Python irrelvancy are vastly overblown. 

So do I. That doesn't mean the situation can't be improved.

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

You mean the people you described this 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.

Right - they all do it however they feel like, and there's not much we
can do about it. That's not *quite* the same as nothing we can do
about it.

> Python (the project) does not.

Correct. On the other hand, the collective of people here certainly
have more experience at dealing with multiple python installations on
one system than any other group in the world. And you suggest that the
advice from that collective experience that setup.py should offer
packagers on how to deal with this situation is - none?

> 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?"

I'm not suggesting any changes to the language. Like you, I'm
suggesting a change to the default install. I happen to believe it
will make most peoples lives easier. 

> This is paradigmatic for why "python3" is a nonsolution.

Just because it doesn't solve your solutions doesn't mean it doesn't
solve anyones. And it's sure as hell better than doing nothing.

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

Yup. So what's the problem with doing the same thing for
python<MAJORVERSIONNUMBER> at the same time?

Personally, I'd rather it just check the install directory and not
$PATH, because you pretty much have to do that if you need different
installs of the same X.Y version. I'd also favor more automation, and
have it offer to run that script rather than just suggest it.

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

Sure, there are *lots* of ways the user can screw up the system as
root. Doing a default python install from source is *not* one of them,
no matter what it does with those symlinks. If you know of a system
where things are otherwise, please warn me about it now.

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

I draw that conclusion based on a decade and a half of installing,
maintaining and upgrading python software.

> (rather than a crock pandering to lazy developers downstream).

Damn straight I'm lazy. Computers - all of them - suck bad enough as
it is. Anything I can do to make my life easier is a win.

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

True. But you act like making it *easy* for people is somehow
criminal.

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

I don't really have a problem with that; I just think we should be
looking beyond the end of our noses - uh, 3.0 - and trying to set
things up to make things easier for the system administrator.

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

But of course they don't. Your "properly specific shebang" will break
on every version of python *after* the one they target, even though
the script would otherwise work. No developer in their right mind
wants to deal with the extra support work that would generate.

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

Personally, I think *this* is a crock. But if you're going to advocate
that people lie about what versions they have installed, then please
advocate having setup.py do something to encourage people to create
systems that look like this, so that app developers have a reason to
use the shebang line you want them to.

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

Right. It's not identical, so you have to do something *different* to
solve this problem. With python2, you set the python2 link back to the
previous version. Yeah, you may have to fix the apps that require the
new version, but oddly enough, the more of those scripts there are,
the less likely it is that one of your old apps will barf on that new
version.

Personally, I think that's a *lot* easier than running around creating
or re-creating a bunch of symlinks every time I install or upgrade
python, much less trying to figure out when I really can declare that
I no longer need some version under those conditions. On the other
hand, if setup.py made setting up the symlinks easy, maybe I'd change
my mind.

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

Much as RHEL may work to remind you that GNU means GNUs Not Unix, it's
still one of the most popular distributions around, and hence liable
to be many people's first exposure to python in a Unix-oid
environment. The more we can do to make that part of their experience
not suck, the more likely they are to consider doing more work in
Python. Not to mention making life better for those of us who have
clients that won't let us include the depenguinator in our list of
required software packages.

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