Status report on python2 transition
First of all the good news: You have managed to talk me into making the
big step, and going right to the 2.1.1 CVS branch. Thomas Wouters
(release czar for Python 2.1.1) assured me that 2.1.1 will be released
before the freeze, and Guido heavily supported that.
Now for the bad news: I don't have any conclusive plan how to manage
transitions for future Python feature releases, like 2.2, 2.3 and so on.
Until now I had the impression that in general it's not necessary to
have more than one Python version on your machine at the same time
(except perhaps you're a Python core developer). Feedback from
python-dev though was that it's definitely necessary to allow and
support multiple concurrent versions of Python even on production
machines.
If we're going to support this in Debian regularly, then it get's even
much more complicated than with our current setup of python-* and
python2-*.
Please have a look at the python-dev archives for the full discussions:
http://mail.python.org/pipermail/python-dev/2001-July/015715.html
The discussion
--------------
- Python has now a reliable, well-behaved version numbering policy:
- feature releases: may introduce new features, may change the bytecode
format. The minor (middle) version number changes (e.g. 1.5.2 ->
1.6, 2.0 -> 2.1).
- micro-versions: bug fixes only, bytecode format can't vary. Only the
micro component of the version number changes (e.g. 1.5.1 -> 1.5.2
or 2.0 -> 2.0.1).
- site-python is depreciated;
Python code should go into a version specific directory (originally I
thought I might use site-python for all packages--would make Python
updates very much easier):
Greg Ward <gward@python.net>:
> Oh yeah, another thing I vaguely recall from the pre-Distutils-0.1
> era: Guido doesn't (didn't?) like site-python and wanted to
> deprecate it.
...
> BTW, I'm skeptical about keeping .py and .pyc code in a
> non-Python-version-specific directory (ie. site-python). Debian's
> bytecode-recompilation at installation time scheme sounds cool, but the
> desire/need to have multiple Python versions available kind of nixes it.
"Fred L. Drake, Jr." <fdrake@acm.org>:
> Another reason not to use site-python is that it is actually still
> hard to write cross-version Python code -- there are enough
> differences that any substantial volume of code (and in Python, you
> don't need many KLoC to get substantial code!) is bound to encounter
> a few, especially if you get used to using only Python 2.0+ -- it's
> easy to get used to features like string methods, list
> comprehensions, and augmented assignment! The site-packages
> directory was introduced to avoid the deficiencies of the
> site-python directory.
Guido van Rossum <guido@digicool.com>:
> Indeed, /usr/local/lib/python<major>.<minor>/site-packages/ is
> where site packages should go.
- Support for multiple concurrent Python versions on the same system is
necessary:
"Barry A. Warsaw" <barry@digicool.com>:
> GH> Seriously, does anybody (besides the Python developers) feel a
> GH> need to have multiple Python versions on the same system ?
>
> Yes, definitely as both a Zope and Mailman developer <wink> I need
> multiple Python versions. But I suspect even normal users of the
> system will need multiple versions. Different Python-based apps are
> requiring their users to upgrade Python on their own schedule, so
> multiple versions will still be required.
"Fred L. Drake, Jr." <fdrake@acm.org>:
> Another excellent reason to support multiple versions! As more
> widely distributed applications are written using Python and don't
> want to include the interpreter, this becomes a more noticable
> issue.
- If we want to support concurrent Python versions and still don't want
to have multiple packages for each Python extension, a setup like the
Debian Emacsen system might be a solution:
Thomas Wouters <thomas@xs4all.net>:
> None are compatible. This might change, but I don't think so -- I
> think the CVS tree already has a different bytecode magic than 2.1,
> though I haven't checked. Perhaps what Gregor wants is a set of
> symlinks in each python version's site-packages directory, to a
> system-wide one, and a 'register-python-version' script like the
> emacs/xemacs stuff has that adds those symlinks. That way, the
> .pyc/.pyo versions would remain in the version-specific directory.
Conclusions
-----------
I have no final conclusion what that means for our Debian Python policy.
For one, I've changed my mind and accepted that there's a need to
support multiple concurrent Python versions in Debian.
The way we're doing this currently for python-* and python2-* is
certainly no good--it means duplication of work, and it's a mess when it
comes to installing a new version.
If it's possible to do this before woody, by any means I would go that
way. Everything else will be a mess later on.
We should look at the perl packages (they support concurrent versions)
and a Emacsen (they have a system for registration of .el files that can
be byte-compiled at installation time, and they support this for
concurent and different Emacsen flavors).
Please comment on this.
I'll by on Linuxtag this Friday and this Saturday. Anybody else there ?
Gregor
Reply to: