When should Python 3.3 become the default?

[Barry Warsaw]

On Oct 19, 2012, at 12:41 PM, Steve Langasek wrote:

>The set of existing software in quantal that depends on python3.2 is still
>comparatively small: less than 500 packages all told (source+binary).  I
>haven't sorted through to see how many source packages this actually is, but
>it's probably closer to 300 total.  (This compares to python2, which has
>4705 source+binary revdeps in the archive.) Some fraction of these packages
>will require additional porting to make them work with python3.3, but it's
>not clear to me how much that work is.  Do we have some way to estimate?

A test rebuild of the archive with 3.3 enabled would of course be the
definitive answer for the number of broken packages.  We'd have to then look
at the classes of failures, and then analyze how much work it will be to fix
those failures.  Another metric would be searching PyPI for packages that
claim Python 3 or 3.2 support but without explicit 3.3 support.  I'm not sure
how accurate or relevant for Ubuntu/Debian that report would be.

>If the python3.2->python3.3 porting work is small enough to do in one cycle,
>I think it's beneficial for us to focus on this porting exclusively and
>*not* worry about making packages work with both python3.2 and python3.3,
>because that's incidental to our actual goals.

Fair enough.  We already know that there are some packages which can't build
for multiple versions of Python 2, and a few of these have proven fairly
challenging to fix the packaging on.  I definitely agree though that I'd
rather be spending *my* time on porting from 3.2->3.3 or Python 2->3.3 this
cycle.

> - It avoids us blocking on bugs in packages / tooling that prevent
>   supporting multiple versions of python3 today.  We obviously need to fix
>   those *eventually*, but it's not something that's going to be a priority
>   in Debian right now due to the freeze, so if we don't have to deal with
>   it right now we'll spare ourselves having to carry a delta.
> - As we identified at last UDS, there are advantages to porting directly to
>   python3.3 when coming from python2.  Getting python3.2 entirely out of
>   the picture should, over the slightly longer term, buy us back some
>   effort when it comes to the python2->3 transition.
> - It sends a clear signal to upstreams that they should be targeting 3.3,
>   not 3.2.  Yes, this may again hurt our python3 support in the short term
>   because some software supports python2 + python3.2 upstream and not
>   python3.3; but I think getting python2 off the CD for 13.04, only to have
>   to ship both python3.2 and python3.3 instead, is not really a win for us.
> - Python 3.3 has multiarch support and 3.2 does not.  So keeping 3.2 around
>   has implications for cross-bootstrapping of Ubuntu, which is also on the
>   list of topics for UDS.

I agree with all these points.

>So here's my strawman proposal.
>
> 1) Open raring with python3.2 as default, and only, supported python3
>    version.
> 2) Fix the issues that prevent dh_python3 being used for python3.3, ASAP.
> 3) Stage rebuilding all of the python3 revdeps against python3.3 in a ppa.
>    Identify all build failures.  Determine if these are tractable to sort
>    out for raring.  If not, go to step 6.
> 4) Iterate in the PPA (pushing the necessary support patches to Debian,
>    upstream, or raring as we go) until enough of the set is buildable with
>    python3.3 that uploading it is not going to be disruptive to other
>    development.  Focus in particular on python3.3 compatibility in those
>    packages which build-depend on python-all-dev.
> 5) Upload to raring, switching to python3.3 in one go.
> 6) If we determine that we can't make it all the way up the hill to
>    3.3-only in time for raring release, back off: make python3.3 a
>    supported version, but make 3.2 the default.
>
>Please tell me if this sounds crazy.

Not crazy at all.

Given that we'll probably have to do some rebuilds *anyway* at some point in
raring, this sounds like a reasonable plan.  I've added these steps to the
whiteboard of:

https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-python-versions

and will begin to add work items for them.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20121019/8e10c933/attachment.pgp>