On Sun, 2008-06-01 at 17:36 -0400, Jeremy Katz wrote:
Toshio Kuratomi wrote:
> The python programming language is going to be releasing a new version
> sometime around the time of the Fedora 10 release. Unlike past
> releases, this one will have wide-spread backwards incompatibility in
> the python language itself. We need to think about how we want to pull
> the new language into the distribution and porting of existing
> apps/modules. Here's a proposal to start us off but I hope geppetto
> (the python maintainer) and ivazquez (who maintains python3.0 packages
> in his spare time_) will weigh in with their thoughts.
So, while this is a large and incompatible change, there are lots of
other large and incompatible changes that we've managed over the years.
And in most of those, we've been far better off with actually making
a transition rather than trying to keep two different things around.
While you obviously have more direct experience than I, can you think
of a case where a change was this large and incompatible?
This is even _more_ true with things which are a framework that lots
other packages provide modules for -- things like apache, perl, python,
and more. So in contrast, I think that we should evaluate python 2.6
for Fedora 10 (it seems reasonable, but I will defer to the current
python maintainer's judgement :-).
I completely agree.
In theory the change will be smaller and less incompatible if you first
port to the subset of python-2.6.z that is most compatible with
python-3.y.z, however I've not seen anyway to test that you've
successfully done this apart from inspecting the code by hand.
And the move to python 3.0 will need
to wait until there's either
a) sufficient reason for us to do a lot of legwork to get there or
b) enough upstreams are "buying in"
> * python3000 modules should have a separate namespace from python2.x
> modules. The packaging committee will need to decide on that
> (python3-foo, python3000-foo, python3k-foo are possibilities.
> python3.0-foo should not be considered as 3.x versions should not have
> the same backwards incompatibilities that 2.x->3.x has.)
Except that many python modules are just included in with packages or in
the same source tree. This then ends up with a need to build multiple
versions of python modules and that way lies massive amounts of pain.
It was a huge enough pain for just a very small number of modules in the
python 1.5 -> python 2 transition. With the vastly greater number of
modules these days, it becomes far far more difficult.
Right, all of the bindings will be a big pain point (does swig support
Also having every package that uses python be renamed from foo to
py3k-foo is horrible ugliness we'll have to live with forever.
> * Porting to python3000 will occur at some point but that should
> post-Fedora 10 feature that we decide on after python-3.0 final has been
> released. We will also need to discuss whether to port our tools
> piecemeal or altogether at that time and to what extent (if any) we will
> allow splitting from any upstreams that only support python-2.x.
It's not as simple as that. What happens if (just to make up an
example), anaconda and rhpl move to python 3 but no other tools do?
Especially given that other tools depend on rhpl. Either a) the other
tools have to be ported or b) multiple copies of the same code have to
be maintained. The latter is filled with losing. The former is
plausible, but it is going to be a big effort and we have to
consistently commit to it across the board.
Probably the most interesting python application is yum, as if it
breaks you can't easily update/install to fix anything, and it currently
pygpgme - binding
rpm-python - binding
yum-metadata-parser - binding
...now all of those and yum need to move to the "py3k language" as one
unit, and as far as I can see there's no way we can do that
automatically without renaming everything (at which point we don't need
James Antill <james.antill(a)redhat.com>