Let's make a plan for python3.0 in Fedora 10+

[James Antill]

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[1]_) 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 of 
> 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
py3k yet?).
 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 be a 
> > 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
depends on:

pygpgme              - binding
python-iniparse
rpm-python           - binding
urlgrabber
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
to).

-- 
James Antill <james.antill at redhat.com>
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080602/ea1cef06/attachment.bin