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