Python 2.7 is out

[Jason W]

Python-2.7.tcz has been fixed and uploaded.

[Jason W]

pygtk-2.7, pygobject-2.7, pycairo-2.7, pyusb, and urwid uploaded.

[Arslan S.]

weird file list are you sure they are compiled against python-2.7 ?

Edit: sorry i think i clicked on wrong link

[Arslan S.]

I need at least these extensions build against python-2.7 please ?

sip
pyqt
dbus-python
python_libxml2
pyrex
pyorbit

[Juanito]

I'll have a look at dbus-python, pyrex and pyorbit

[Juanito]

dbus-python-2.7, pyorbit-2.7, pyrex-2.7 posted

[bmarkus]

After migrating applications to Python 2.7 we have to remove 2.7 from extenson names and go back pygtk.tcz pyrex.tcz etc. and keep Python 2.7 as the main Python version. Hopefully there will be no 2.8 released and 2.7 is really the last 2.x

[bmarkus]

  WICD is not compatible with Python 2.7 according to my recent tests. Google returns similar posts with other distros too.

It is already in the WICD bug tracking system.

[Jason W]

So far, using the -2.7 suffix has been generally agreed upon for python related extensions built against version 2.7.  But there are packages built against python 2.7 that have been submitted without the python suffix in the name.

To avoid conflict and confusion, let's please stay with using -2.7 in the extension name for python 2.7 related packages.  I strongly prefer that we always use a python version suffix in python package names to ensure a smooth and seamless upgrade between python versions from here on without any mass renaming of extensions and their .dep file references that will break existing tce directories.

I am open to ideas on this subject, but I think we need to consider the future and remember we will surely be doing this again in the coming months or year.  And a smooth and non-broken transition is paramount.

[Arslan S.]

What is the current status of python extensions in need of building with python 2.7 ?

[Juanito]

Based on checking which extensions contain "python2.6/site-packages" AND do not contain "python2.7/site-packages" AND for which extension_name-2.7 does not exist, I come up with:

Code: [Select]

bitbake.tcz.list
boost-dev.tcz.list
boost.tcz.list
bzr.tcz.list
dictclient.tcz.list
django-1.1.1.tcz.list
farsight2-dev.tcz.list
farsight2.tcz.list
feedparser.tcz.list
gammu.tcz.list
git.tcz.list
gnome-colors.tcz.list
gpsd-python.tcz.list
graphviz.tcz.list **
gtk-vnc-dev.tcz.list
gtk-vnc.tcz.list
libftdi-dev.tcz.list
libftdi.tcz.list
lilypond-2.12.2.tcz.list [python-2.4]
mercurial-1.2.1.tcz.list [python-2.5]
nicotine.tcz.list
oo2.tcz.list [python-2.3.4]
psyco.tcz.list
pybsddb-dev.tcz.list
pybsddb.tcz.list
pyogg-vorbis.tcz.list [python-2.5]
pyopenssl.tcz.list
PyPanel.tcz.list
pysqlite2.tcz.list
pysqlite.tcz.list
python_coherence.tcz.list
python-keybinder.tcz.list
python-xlib.tcz.list
recordmydesktop-gtk.tcz.list
rsvg.tcz.list
SQLAlchemy.tcz.list
supybot.tcz.list
telepathy-farsight-dev.tcz.list
telepathy-farsight.tcz.list
wicd.tcz.list
xcb-proto.tcz.list
xpyb-dev.tcz.list
xpyb.tcz.list
zenmap.tcz.list
zeroinstall-injector.tcz.list
zfs-fuse.tcz.list
I did not double-check every single extension, so there could be some mistakes in the above.

[Arslan S.]

some notes about the list above:

* boost python is not available in boost.tcz (i wish it had), files in python2.6 directory belong to python.tcz and have no relation with boost
* gnome-colors is a set of icon themes (have some icons with name python)
* rsvg module for python 2.7 is available in gnome-python-desktop
* i will take care of gtk-vnc, telepathy-farsight (needs farsight2-2.7 first) , and maybe gpsd if last packager does not want to do it
* weird why vtemodule is not listed ?

[Jason W]

There still a few extensions using python 2.6, and some like WICD will not work with python 2.7. 

I am personally more concerned about our strategy than I am about how many extensions have been updated to 2.7.  If we are happy with using the python version in the names of python related extensions, then there is no hurry to upgrade or rebuild.   But having the python version number in the name and supporting 2 versions of python can make the repo a little more cluttered and perhaps confusing especially to newer users.  If we want to be able to have python upgrades in between major TC releases, then it is really about the only way to go.  Otherwise, I think that future python upgrades would need to only take place during a major TC version change if we are going to require current extensions be rebuilt with the goal of supporting only one version of python.  There are advantages with either approach.

I just want to make sure we are all on the same page before we proceed further.

[Jason W]

Juanito had mentioned earlier today, and Arslan mentioned earlier in the thread, that we could rename the python 2.6 related extensions with the 2.6 suffix, therefore freeing the new python stuff to be without a version number tacked on.  Not the easiest way, but perhaps the more palatable for users and extension makers alike.  One large renaming, and then the new python extension and its dependent extensions would not require the 2.x suffix.  And when a new TC major version is released, the old python stuff with the version number is left behind in the old repo, while the new stuff gets carried over.

It is technically no different than just using a version number in the name of all python extensions, and would require a 'one time per update' mass renaming that using the version number would never require.  But I am willing to go that route if it sounds more like what the community would like to do.

The more I ponder it, I think renaming the 2.6 stuff with the 2.6 suffix is probably a good idea anyway, at least to identify it as 2.6 related just as the 2.7 does for the 2.7.   Perhaps letting 2.6 stuff remain without the version number is giving the impression that 2.6 is the main (latest) python version, as well as being confusing as to it's version.

[Jason W]

Looking at what would need to be done to properly support 2 concurrent versions of python, I think that we do after all need to stick to one version of python in the repo.  And upon major TC upgrades, it can then be discussed if python needs to be updated, and then we would keep to that one version for the duration of that major TC release.

What we can do now is to focus on updating and retiring the 2.6 stuff, keeping only what will not run on 2.7 and labeling it with the -2.6 name.  Though in theory supporting 2 pythons could work, it would require further factoring out the python parts of extensions, and add more complexity to figuring dependencies and all.  It is a level of complication that I am sure we agree we don't need.

I thought that supporting multiple python versions would allow a smooth upgrade process, but the more I look into what would need to be done to reduce file and extension conflict, I see that it is just digging a hole.  I got is into that hole, and I will try to help get us out as best I can.