increasing the python requirement

Toshio Kuratomi a.badger at gmail.com
Wed Jan 5 06:21:35 UTC 2011


On Wed, Jan 05, 2011 at 11:21:26AM +1100, Martin Pool wrote:
> 
> I suppose improvement that are only in Python 3.x do fit here, but
> that's a somewhat separate discussion: "when should we support 3.x?",
> and then only secondarily "will dropping 2.4/5 help us support 3.x"?
> It seems like it will help a bit but it's not the main thing.
> 
> Let's suppose someone came up with a branch that cleanly supported 2.6
> and 3.x, and they said they found it impossibly hard to also support
> 2.4 from the same codebase.  Quite possibly this would be faster on
> 3.x than we are at the moment on 2.x.  Eventually we'll support 3.x.
> Will we do it as soon as bzr2.4, if it means no more support for
> python 2.5?  I think it could be a reasonable tradeoff.
> 
<nod>  python3 is an interesting target.  In Fedora, we have parallel
python2 and python3 stacks even though we don't have parallel python2.4
python2.5 python2.6 python2.7 stacks.  We consider them separate enoguh
languages that we need to have both of them.

In RHEL, neither RHEL5 nor RHEL6 ships with python3.  We (Fedora EPEL
Project) ship python3 for RHEL5 in the EPEL5 repository and likely will also
ship it in the EPEL6 repository so we might be able to update if needed.
There's a few caveats to that though:

1) python3 makes releases just like python2 -- so you may ship python-3.2
compatible code but some distributions may only have python-3.1.  (EPEL5 is
currently shipping python-3.1 since 3.2 isn't released yet.  python-3.0
isn't recommended so hopefully you wouldn't have to worry about it.  EPEL
tries to follow the same release methodology as RHEL so EPEL wouldn't ship
python-3.2 as it'll break people depending on the python3 package to not
break compatibility).

2) In RHEL6, there's a bzr package in RHEL proper.  Unfortunately, that
means if bzr is ported to python3, RHEL6 will have to continue to ship the
old version that runs on python2.  (There lots of permutations here, of
course -- if bzr runs on both python2.6 and python3.x then RHEL6 can ship
updates since it comes with python2.6.  If there's only a python3 version of
bzr, RHEL6 could choose (I'm not sure it's likely, though) to ship a python3
stack sufficient to ship the new bzr.  The bzr maintainer in RHEL may decide
that they just aren't able to ship an updated bzr due to API changes
in bzrlib no matter whether the newer bzr supports python2.6 or not...)


> On the other hand, when we come to try that work it might turn out
> that it's hard to support both 2.6 and 3.x, or on the other hand that
> supporting 2.5 is no harder than supporting 2.6.  I've seen anecdotes
> supporting any of these positions so I think the only thing is to
> actually try it in bzr.
> 
I very much agree with you here.  Until someone takes a stab at converting
the code and testing it under python3 you won't really know what versions
can be supported.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20110104/ea1e150c/attachment.pgp>


More information about the bazaar mailing list