Python 2.7 for Maverick

[Barry Warsaw]

On Jun 16, 2010, at 03:58 PM, Scott Kitterman wrote:

>The needed rebuilds can be scripted.  That's not the primary concern.  It
>will be first trouble shooting the build failures (some of which will be
>directly Python related and some won't). Then it will be trying to find and
>fix issues with packages not working correctly with 2.7.

That makes sense.  Enabling Python 2.7 now, but not making it the default
allows us to build out the stack, but also iron out any problems in a PPA so
that as soon as N opens, we can just flip the switch.

Speaking of which: I'm building out a py27 stack in the ~pythoneers PPA:

https://edge.launchpad.net/~pythoneers/+archive/py27stack

Any and all suggestions are welcome.  If you add this PPA, you'll need to
manually install python2.7, then apt-get upgrade to get the Python 2.7-enabled
packages in the PPA installed.  I've tested this with a simple,
no-other-dependency package like python-fstab and it seems to work on a
Maverick VM.

Right now, I'm doing manual uploads, but I hope to write a script to work out
the build dependency tree and do automated uploads.  If you know of anything
that already exists which would jumpstart that, I'd love to hear about it!

>>We're only talking about builds, right?  We don't actually know how many of
>>those packages are not compatible with Python 2.7.  This is I think the bigger
>>risk, however, in my experience as Python's release manager, we will never
>>really know until we make Python 2.7 the default.  People just don't test
>>their stuff until forced to.
>
>To an extent that's true, but I'd much rather make it the default during tool
>chain setup for Maverick +1 so we get the full cycle to work at it and more
>of the needed rebuilding will get done as part of the natural churn of the
>archive.
>
>I'd also like time to get this into Debian Experimental and see what benefit
>accrues from it.
>
>I'll point to the 200+ bugs just now filed in Debian about string exceptions
>being removed as an example of how latent issues can be left for a long time
>when Ubuntu gets too far ahead of Debian.

It does make a lot of sense to be able to use the M-cycle to build out the
stack as best as possible, so that early in N we can flip the switch.  If this
makes Debian's life easier - and utilizes their collaboration too - then it's
a strong argument for doing as you propose.  I'd like to get Matthias's
opinion before we make a decision though.

Note that this doesn't mean I should stop working on this.  On the contrary, I
think we still want to move forward with the plan, stopping just short of
s/6/7/ in python-defaults.  If we go this way then, we'll do that change as
soon as N opens up.

>Falling back is doable (I think), but not easy. Moving the default Python to
>a lower version is not one a use case considered in the current design.

That's important to know.  If falling back just before Mav beta1 is risky,
then that argues for being more conservative.

Thanks,
-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-release/attachments/20100617/b4ca6ab5/attachment.pgp