James Antill wrote:
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?
python 1.5 -> python 2 wasn't this large. But it was pretty large and
ended up requiring a number of source changes in modules.
* 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).
But to keep things more fun, there's a significant body of other stuff
which sits on top of yum now. So all of that will need to be ported at
the same time also. Doom! :)
Jeremy
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
