Python 2.7 is out

[bmarkus]

Python 2.7 is just recently released as the main 2.x version. It shows that there is demand for 2.x and can't be omitted and replaced with 3.x

I have no problem with 2.6 as it is in the repo, but I think this would be good to migrate to 2.7 Last time such and action to 2.6 was smooth without any serious hassles.

Jason:

if you build 2.7 I'm ready to test and rebuild my extensions as last time.

For more info on 2.7 see

http://docs.python.org/dev/whatsnew/2.7.html

[Jason W]

I will go for a build this week.

[bmarkus]

I will go for a build this week.

Fine

[Jason W]

Apps that depend on just python itself can remain with a dependency on python2.6.  But if we wish to update pygtk, pygobject, and pycairo against python2.7, then extensions that depend on them would have to be rebuilt.  Here is a list of pygtk dependent apps, as well as apps that depend on them.  I only recursed about 2 levels, so there may be more:

Code: [Select]

bleachbit-locale.tcz
catfish-locale.tcz
ccsm-locale.tcz
compiz-base.tcz
compiz-gnome.tcz
gedit-dev.tcz
gedit-locale.tcz
gnome-desktop-base.tcz
rabbitvcs-gedit.tcz
compiz-gnome.tcz
rabbitvcs-nautilus.tcz
gramps-locale.tcz
meld-locale.tcz
rabbitvcs.tcz
blueman.tcz
eog-plugins.tcz
gedit.tcz
gnome-desktop-base.tcz
rabbitvcs-gedit.tcz
rabbitvcs-locale.tcz
rabbitvcs-nautilus.tcz
rabbitvcs-thunar.tcz
totem-locale.tcz
wicd-locale.tcz
bleachbit.tcz
catfish.tcz
ccsm.tcz
comix.tcz
emesene.tcz
gedit.tcz
gnome-desktop-base.tcz
gramps.tcz
meld.tcz
nicotine.tcz
notify-python.tcz
postr.tcz
pygtksourceview.tcz
python-gtkspell.tcz
rabbitvcs.tcz
recordmydesktop-gtk.tcz
rhythmbox.tcz
thunarx-python.tcz
totem.tcz
tucan.tcz
tv-player.tcz
wicd.tcz
wifi-radar.tcz
zenmap.tcz
zeroinstall-injector.tcz
bleachbit-locale.tcz
catfish-locale.tcz
ccsm-locale.tcz
compiz-base.tcz
compiz-gnome.tcz
gedit-dev.tcz
gedit-locale.tcz
gnome-desktop-base.tcz
rabbitvcs-gedit.tcz
compiz-gnome.tcz
rabbitvcs-nautilus.tcz
gramps-locale.tcz
meld-locale.tcz
rabbitvcs.tcz
blueman.tcz
eog-plugins.tcz
gedit.tcz
gnome-desktop-base.tcz
rabbitvcs-gedit.tcz
rabbitvcs-locale.tcz
rabbitvcs-nautilus.tcz
rabbitvcs-thunar.tcz
totem-locale.tcz
wicd-locale.tcz


Though several are -locale extensions, there are 73 extensions, 50 of them are from Arslan and the rest are mostly from bmarkus, robc, Juanito, and JLS.  Since I won't be the one doing the rebuilding to upgrade pygtk dependent apps to the just released python, I want to hear from the others who will be affected if it is felt needed to upgrade pygtk related stuff at this time.

[bmarkus]

Impressive list

I'm not sure that all applications depending on pygtk must be rebuilt as they are not depending on Python itself. My suggestion is to provide Python and a new pygtk for private review for extension makers and test.

[Arslan S.]

do we really need to rebuild all of them except extensions which install files into lib/python2.6 ?

if so i can not rebuild all of them in short time, while i am planning updating gnome packages to 2.30.2 they will be rebuild slowly anyways. So just let them stay broken a while.

btw the list has duplicated lines

[bmarkus]

do we really need to rebuild all of them except extensions which install files into lib/python2.6 ?

if so i can not rebuild all of them in short time, while i am planning updating gnome packages to 2.30.2 they will be rebuild slowly anyways. So just let them stay broken a while.

btw the list has duplicated lines

I don't think so. Lets test it on few samples.

[Jason W]

I was under the impression that pygtk had shared libs in /usr/local/lib, but apparently it does not but places it's files in /usr/local/lib/python2.x.  That should mean leaving a pygtk version that is built against 2.6 in the repo, say named to pygtk-2.6, while the pygtk-dev extension that folks would build against would belong to the new pygtk, version 2.7.   Kind of like with boost and icu. 

I will be back on my main machine tomorrow and can build python and upload it for testing.  Hopefully we can realize a sane upgrade cycle that does not require rebuilds.

[Jason W]

Upon a close look, python dependent packages are of course bound to the version of python they are made against, as well as any packages built against those, like stuff dependent on pygtk, all has to be coordinated to that specific python version.  That leaves about three approaches for a python upgrade.  The first time involved few python dependent packages, so it was pretty simple.  Now we have gnome and a whole lot of other stuff that uses python.  

First approach is to rebuild everything to the new python version, and replace the existing python dependent packages and everything that depends on them.  A lot of work, but would be a clean upgrade.

Second is to apply the relevant python version number to python dependent packages, like pygtk2.7, so to know which python they belong to.  This would allow more than one version of python installed at once for those dependent packages, but would not be a clean system and would be confusing.  As well as the fact that there would have to be a separate dependency stack for each python version in the repo supported by this.  That would not result in a clean repo and would be confusing and there would be duplication even if it could be pulled off.  Compiling in that environment would be frustrating to say the least.

Third would be the approach that Debian uses, and that is include support for both versions of python in python dependent apps like pygtk, with files in both /usr/local/lib/python2.6 and /usr/local/lib/python2.7 in the same extension.  Debian can manage it, but I don't think that is either feasible or in the spirit of TC to include both versions in the same extension, with the possible errors and all that it would entail.  

Though I have stated differently during the 1.x days, I dare to suggest that we forgo keeping with the latest python as they are released and instead time the update with a major TC upgrade, starting afresh with a new python extension in the case of an upgrade that requires a recompile, which won't be every time.  Since a major TC version includes a toolchain and kernel upgrade, so many extensions are rebuilt to take advantage of that anyway.  Though it would mean starting from scratch on a TC upgrade that a python upgrade is also decided, at least there is stability within each TC version's repo.  This approach is the only remaining one for an openssl upgrade, and I think python qualifies to be in that same category given the scope of the repo.

Please share any thoughts or ideas.

[bmarkus]

Jason,

We can't keep support for different 2.x versions, there must be only one for sure. However it is not clear for me what is your advice, to keep 2.6 as it is now or move to 2.7 as in last paragraph, being just in a major release update of TC, even if it is a very end of the procedure.

For me both keeping 2.6 or moving to 2.7 is OK as related extensions maintained by me can be easily and safely recompiled using build scripts.

[althalus]

Though I have stated differently during the 1.x days, I dare to suggest that we forgo keeping with the latest python as they are released and instead time the update with a major TC upgrade, starting afresh with a new python extension in the case of an upgrade that requires a recompile, which won't be every time.  Since a major TC version includes a toolchain and kernel upgrade, so many extensions are rebuilt to take advantage of that anyway.  Though it would mean starting from scratch on a TC upgrade that a python upgrade is also decided, at least there is stability within each TC version's repo.  This approach is the only remaining one for an openssl upgrade, and I think python qualifies to be in that same category given the scope of the repo.

Please share any thoughts or ideas.

If this ends up being the chosen route, then I think it would be a good idea to make 2.7 the Python 2.x supported in TC3.x

[Arslan S.]

I already have a plan to upgrade gnome to 2.30.2 so most of them will be build anyways if you are going to upgrade python to 2.7 this is the best time

[bmarkus]

It seems that we are going to update to 2.7 right now

[Jason W]

I just got up and am heading out the door to work now, but I will upload python2.7 when I get home.

I personally don't understand what realistic benefits justify this much trouble, but I won't stand in the way if moving to 2.7 now is what is desired by those who will be doing most of the rebuilding.  If anyone has concerns, now is the time to raise them. But this will need to be done in a manner that does not break the repo.  I will think about how we can go about this today.

[Jason W]

I will be uploading python in a couple hours.  Didn't mean to appear quite so negative my last post, posting just after waking up is not always best.   

I think we can best do this by upgrading the extensions by dependency sets.  In other words, when we build say pyusb against the new python, we make sure that all apps dependent on pyusb get rebuilt at the same time, or at least uploaded at the same time.  That way the old python stays in the repo and apps that use it will still work until they get upgraded.  Pygtk and the gnome stacks will be large, but other than that we should be able to migrate piece by piece.

I am of course open to other suggestions.