Python 2.7 is out

[bmarkus]

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.

Agree to support one version of Python officially only and let user deal with the case when he need a different version.

I do not aware applications which requires definitely 2.7 while WICD doesn't work with 2.7 and according to discussion to the author we can't expect a fix in the near future. Also, 2.6 line is updated frequently (latest is 2.6.6) and works fine.

My proposal is to declare that Python 2.6.x is the only supported in current TC/MC and keep 2.6 up-to-date. 2.7, 2.5 and 3.x nice to have of cource but only for test for the challengers brave enough. In general, build applications against 2.6 except special cases.

BTW, this is de facto the current case, as python 2.6 is called python. SO it is basically just a policy change.

[Jason W]

Since early in this thread, the idea was to migrate to python 2.7, which has progressed to the point there is no turning back.  The issue is on the naming of python 2.7 related extensions, whether to continue to use the 2.7 suffix, as well as that of supporting 2.6 extensions as opposed to replacing them with 2.7 versions.

We really need to get on the same page concerning the python update, and all agree on a path to take.  I want to hear from extension makers that package python stuff and either hear a consensus on the 2.7 naming and possible factoring of python modules in to separate extensions when necessary, or ideas of how to proceed.  But as it is, I think I am forced to rename the python 2.6 stuff with the -2.6 name so that the 2.7 stuff either has the 2.7 suffix or not, and the 2.6 suffix is what distinguishes the 2.6 extensions.

[Juanito]

There's perhaps a choice of whether to rename the extensions using python-2.6 or remove them if they have been replaced by a tested and working python-2.7 version.

If we're going to only change the python version when we change major versions of tc - eg tc-2.x to tc-3.x, I would suggest we can drop the *-2.7, if we might change more often that this, perhaps it's better to keep the *-2.7

[bmarkus]

I'm fine having 2.7 is the standard supported. The most importans is that Jason have to make the statement and publish guidlines on (re)naming Python components.

I will follow.

[Jason W]

Since we are already doing the -2.7 naming, it is probably best to just stick with that and leave the 2.6 stuff alone.   It so far as worked well, just needs to be universally followed at this point, and then with TC 4.0 we can then either move the 2.7 stuff over to the 4.x repo or decide to use a more recent release. 

There is at least one extension, libproxy, that may need it's python stuff separated into a libproxy-python-2.7 extension for the 2.7 component, and maybe libproxy-python for the 2.6.  We can deal with those cases as we see them.

So what I will do is check to make sure that 2.7 related stuff is named 2.7 when it comes in.  And there are also a few extensions that have 2.7 stuff that will need to have the 2.7 suffix added to them.

[Jason W]

Here are extensions that depend on things that are built with python-2.7 and python.tcz.  May or may not cause an issue, but here is a list.

compiz-gnome.tcz.tree
pidgin-dev.tcz.tree
rhythmbox.tcz.tree
wicd-locale.tcz.tree

[Juanito]

rhythmbox-2.7 has been posted a week or two now, so rhythmbox could be removed from the repo.

[Jason W]

ok.

[Jason W]

Upon looking at our present python situation, it appears that many of the python extensions have been rebuilt for 2.7 and have a 2.7 version available.  Perhaps we could aim for the replacement and retirement of the python 2.6 related extensions to simplify things since we are already pretty far down the path.

[bmarkus]

Here are extensions that depend on things that are built with python-2.7 and python.tcz.  May or may not cause an issue, but here is a list.

compiz-gnome.tcz.tree
pidgin-dev.tcz.tree
rhythmbox.tcz.tree
wicd-locale.tcz.tree

wicd-locale is just a set of locale files and has wicd.tcz as a dependency. wicd.tcz itself depends on Python-2.6 and doesn't work with Python-2.7

[Jason W]

From bmarkus in the /usr/bin/python symlink thread:

Maybe I'm wrong, but for me python.tcz is the python extension while python-2.7 is the new till it will be renamed to python.tcz and the current pytho.tcz to python-2.6 to tcz.

I thought the general understanding is that python-2.7 is the current one to use and build against, while the 2.6 python is only to support existing extensions until they are replaced.  But even this small symlink issue points out the confusion that is resulting from having 2 python versions while updating python stuff in the middle of a release.

Looking back, it would have been more clear if the 2.6 stuff would have been named with the 2.6 suffix before we even started building against 2.7.  But then we still would have had the issue of the main python version not being python.tcz.  And either way we have a mass renaming effort to deal with.  

I know that wicd does not work with python-2.7, but aside from that I am about ready to say why don't we just remove all the 2.6 related extensions since most have been replaced with 2.7 versions.  Then if there were any removed that did not yet have updated versions, they could just be built and submitted then.  Obviously, that would only happen if the affected extension makers who are active agreed on it, or if some agreed but wanted time to replace stuff, then only after that time.  But I could quit making the Tylenol stockholders happy with high share prices that are resulting from my purchases, and those of other extension makers, if we did go that route.  I am ready for this python issue to reach a conclusion and be behind us, and I am sure I am not alone.  

Removing the 2.6 stuff except for wicd and it's deps will require some rebuilding in the near future, which was planned anyway with updating python.  Not removing or just renaming 2.6 stuff will still result in file conflict and confusion, sapping resources in time and energy that could be spent in moving forward.

The bulk of the python stuff is from bmarkus, robc, Kingdomcome, Arslan, Juanito, and JLS, and not necessarily in that order in terms of number of extensions.  Here is a list I made a couple weeks ago, but should still be complete.  I think these either need to be updated if not already, or removed or updated by someone else if the owner is no longer active.  Most of the important ones have been updated by now.  I am not asking which ones we want to remove, it is much more to the point to ask which ones you want to keep or would like to be allowed time to upgrade.  

I will remove nothing without permission, and this is not a pattern for the next python upgrade, but rather just bailing us out of a potentially growing mess.  I am open to other ideas, but at this point I think anything less than aiming for the removal of the old python stuff may just add to the issues we are seeing.   Python 2.7 stuff then can be renamed back to not having the 2.7 suffix, and some are already named without it.

EDIT:  wicd and it's deps will of course remain, perhaps with a 2.6 suffix, and they will only be a few extensions.

Code: [Select]

BeautifulSoup.tcz
Extension_by:   Thomas Genty <tomlohave@gmail.com>
 
PyPanel.tcz
Extension_by: Kingdomcome
 
SQLAlchemy.tcz
Extension_by: Kingdomcome
 
avahi.tcz
Extension_by:   juanito
 
bitbake.tcz
Extension_by:   robc
 
blueman.tcz
Extension_by:   juanito
 
boost.tcz
Extension_by:   robc
 
bzr.tcz
Extension_by: Kingdomcome
 
dbus-python.tcz
Extension_by:   juanito
 
dictclient.tcz
Extension_by: Kingdomcome
 
django-1.1.1.tcz
Extension_by: Althalus
 
farsight2-dev.tcz
Extension_by: jls_legalize (unsenepopiu at tin dot it)
 
farsight2.tcz
Extension_by: jls_legalize (unsenepopiu at tin dot it)
 
feedparser.tcz
Extension_by: Kingdomcome
 
gammu.tcz
Extension_by:   bmarkus
 
git.tcz
Extension_by: juanito, jls_legalize, SvOlli
 
gpsd-python.tcz
Extension_by:   Arslan S., T. Buctoo
 
gst-python.tcz
Extension_by:   juanito, Arslan S.
 
gtk-vnc-dev.tcz
Extension_by:   Arslan S.
 
gtk-vnc.tcz
Extension_by:   Arslan S.
 
hplip.tcz
Extension_by:   juanito
 
kaa-base.tcz
Extension_by:   Thomas Genty <tomlohave@gmail.com>
 
kaa-display.tcz
Extension_by:   Thomas Genty <tomlohave@gmail.com>
 
kaa-imlib2.tcz
Extension_by:   Thomas Genty <tomlohave@gmail.com>
 
kaa-metadata.tcz
Extension_by:   Thomas Genty <tomlohave@gmail.com>
 
libftdi-dev.tcz
Extension_by:   robc
 
libftdi.tcz
Extension_by:   robc
 
libgsf-gnome.tcz
Extension_by:   juanito
 
libproxy.tcz
Extension_by:   juanito
 
nicotine.tcz
Extension_by:   jls_legalize (unsenepopiu at tin dot it)
 
notify-python.tcz
Extension_by:   Arslan S.
 
pil.tcz
Extension_by:   juanito
 
psyco.tcz
Extension_by:   robc
 
pybsddb-dev.tcz
Extension_by:   robc
 
pybsddb.tcz
Extension_by:   robc
 
pycairo-dev.tcz
Extension_by: jls_legalize (unsenepopiu at tin dot it)
 
pycairo.tcz
Extension_by: jls_legalize (unsenepopiu at tin dot it)
 
pygame.tcz
Extension_by:   Thomas Genty <tomlohave@gmail.com>
 
pygobject-dev.tcz
Extension_by: jls_legalize (unsenepopiu at tin dot it)
 
pygobject.tcz
Extension_by: jls_legalize (unsenepopiu at tin dot it)
 
pygtk-dev.tcz
Extension_by: jls_legalize (unsenepopiu at tin dot it)
 
pygtk.tcz
Extension_by: jls_legalize (unsenepopiu at tin dot it)
 
pylirc.tcz
Extension_by:   Thomas Genty <tomlohave@gmail.com>
 
pyopenssl.tcz
Extension_by: Kingdomcome
 
pyorbit.tcz
Extension_by:   juanito
 
pyqt.tcz
Extension_by:   robc
 
pyrex.tcz
Extension_by:   juanito
 
pyserial.tcz
Extension_by:   juanito
 
pysqlite.tcz
Extension_by: Kingdomcome
 
pysqlite2.tcz
Extension_by: Kingdomcome
 
python-dev.tcz
Extension_by:   Jason W
 
python-keybinder.tcz
Extension_by:   blofsy
 
python-xlib.tcz
Extension_by: Kingdomcome
 
python.tcz
Extension_by:   Jason W
 
python_coherence.tcz
Extension_by:   juanito
 
python_configobj.tcz
Extension_by:   juanito, Arslan S.
 
python_libxml2.tcz
Extension_by:   juanito, Arslan S.
 
python_setuptools.tcz
Extension_by:   juanito
 
python_twisted.tcz
Extension_by:   juanito
 
python_zope.interface.tcz
Extension_by:   juanito
 
pyusb.tcz
Extension_by:   bmarkus
 
recordmydesktop-gtk.tcz
Extension_by:   robc
 
rsvg.tcz
Extension_by:   blofsy
 
sip.tcz
Extension_by:   robc
 
supybot.tcz
Extension_by: Kingdomcome
 
telepathy-farsight-dev.tcz
Extension_by: Arslan S.
 
telepathy-farsight.tcz
Extension_by: Arslan S.
 
urwid.tcz
Extension_by:   bmarkus
 
vtemodule.tcz
Extension_by:   bmarkus
 
wicd.tcz
Extension_by:   bmarkus
 
xcb-proto.tcz
Extension_by:   robc
 
xpyb-dev.tcz
Extension_by:   robc
 
xpyb.tcz
Extension_by:   robc
 
zenmap.tcz
Extension_by: Key, juanito, Robert Schumann
 
zeroinstall-injector.tcz
Extension_by: jls_legalize (unsenepopiu at tin dot it)
 
zfs-fuse.tcz
Extension_by: Daniel Barnes
 



[bmarkus]

My proposal is to rename

python.tcz -> python-2.6.tcz
python-2.7 -> python-2.6

as well as related extensions, like pyusb, pyserial, pygtk, ...

It would make clear for everybodey that 2.7 is the officially supported vetsion. For those who are not aware of histry and details just looking for Python and would go for python.tcz it would install 2.7 by default.

[Jason W]

I think that is a good start, I don't have time today and maybe not this week, but that can be the goal.  Especially if we can also retire some of the 2.6 stuff, that would go a long way.

So for now a renaming to -2.6 for old python stuff, and the more we can eventually retire the simpler things will become. 

[jls]

I don't understand why meld should be called meld-2.6.
This program is a user program, with a gui and is not a dep of nothing.

[Jason W]

It it is a dep of nothing, then I guess it could stay meld.

I guess that libraries and other stuff that are listed in dep files are really the ones that need version numbers, end use apps can stay without them.
 

Believe me, I will be happy when the version names of python stuff are not needed.  Hopefully soon.