[csw-maintainers] Support for multiple Python versions

[Ben Walton]

Excerpts from Maciej (Matchek) Blizinski's message of Thu Oct 14 20:00:08 -0400 2010:

> Hard to upgrade by replacing.  Would be easier with an overlap:
> introduce the new one, build modules for it, then retire the old one
> when the time comes.

Lets look at the Debian Python Policy.  It seems pretty sound and I'd
put it forward as a good (proven, working) model:

http://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html#s-versions

I like the wording:

"Apart from the default version, legacy versions of Python or beta
versions of future releases may be included as well in the
distribution, as long as they are needed by other packages, or as long
as it seems reasonable to provide them. (Note: For the scope of this
document, Python versions are synonymous to feature releases,
i.e. Python 2.5 and 2.5.1 are sub-minor versions of the same Python
version 2.5, but Python 2.4 and 2.5 are indeed different versions.)"

This makes sense, I think and would also fit with pushing multiple
versions of ruby.  (A separate topic.)

> > I think that, similar to ruby, we might be best served with a
> > "primary" version of python, and then some "if you really need it"
> > versions.  primary version gets /opt/csw/lib/python or whatever.
> 
> Sure, that's not a problem.  It can be also driven by alternatives
> so users have the choice.

Alternatives is the way to go with this.  Newer python versions get a
higher priority and the admin can locally change this preference.

> However, this does not necessarily mean that we need to remove
> modules for the old version of Python and its modules.  We can have
> py26_twisted built for Python 2.6 and py27_twisted built for Python
> 2.7, happily living together in one file system.

Yes.  Python modules/packages should depend on the version number
(major.minor) that they were originally packaged with.  A new python
release can be made and modules updated slowly.  This _should_ allow
for fewer surprises and more stability.

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302