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

[Mike Meyer]

On Mon, 04 Feb 2008 12:55:29 +0900 "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
> Greg Ewing writes:
> I wonder how many people out there will be "surprised" by sudden
> changes in the version of Python installed.

It's happened in the past. I've been dealing with supporting multiple
incompatible versions on the same hosts for the last two years, and
users running the "wrong" python was a regular occurrence until I
convinced people that it really mattered.

> On Mac OS X 10.4 + MacPorts, MacPorts does not install an
> /opt/local/bin/python at all, so that although /opt/local/bin takes
> precedence over /usr/bin, you get the default Mac OS X install of
> Python 2.3 as "python".

Actually, Leopard comes with 2.5.1. Kudos to jkh & his team for the
upgrade. Also, /opt/local/bin should only take precedence for users;
commands run via sudo and from OS X applications that didn't come from
MacPorts should ignore /opt/local/bin.

> Linux distributions (at least Debian and Gentoo) "anoint" a
> particular Python version as the one that infrastructure software
> uses and that is the default unless the user explicitly sets a
> different version as "python".

And Red Hat. And - since all three provide (well, I haven't checked
Gentoo in a while) system tools that use their "anointed" python - any
distribution that uses those tools (most notably Ubuntu). Further,
those tools depend on third party modules that may only be available
as part of that OS release, so replacing the system python is a
seriously bad idea.

> Installing multiple versions of Python does not reset the "python"
> link.

Depends on how you do the install. The standard python source
distribution will install the python link with "make install", but
installs things in by default /usr/local, so won't break the system
python, or most of the system tools (some do use #!/usr/bin/env python
instead of #!/usr/bin/python). If you do "make altinstall", it won't
install that symlink. If you configure it to install in /usr instead
of /usr/local and do "make install", the python symlink will get reset
(and if you're on one of those Linux systems, your life is about to
get really, really unpleasant).

I haven't looked at the macports version in a while, but suspect that
it used the altinstall target to avoid surprises. On the other hand, I
had no problems on Tiger adding the symlink to /opt/local/bin, and
making sure it was first on my path (but not roots!).

> So it seems to me that this particular issue can easily be handled if
> Python source builds by default only install a "python" link if (a)
> there is none or (b) the newly installed version is an upgrade of the
> current "python".

Neither of those is really good enough. How do you decide that "there
is none"? leaving it in the hands of the installers is the only sure
solution. For the second part, if you upgrade the python without
making sure you've upgraded *all* the third party modules in the
python library, you'll break scripts that depend on the modules you
didn't upgrade.

Living with multiple python installs isn't really a problem. Upgrading
an existing installation isn't really a problem, either. Both work
fine if done with a bit of care. It's up to the person building the
distribution (or doing the install) to make provide that care. But
we've been doing it for a while now, and it's not a serious issue.

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