Python 2.7 is out

[Jason W]

python-2.7.tcz and python-2.7-dev.tcz is uploaded.  Let the fun begin.

I think that python should always have a version number, even the main one, given it's upgrade and compatibility nature.

[bmarkus]

When python-2.7.tcz installed from the repo on a clean TC 3.0rc1 files.tar.gz is not extracted, there are no python binary in /usr/local/bin

Restarting the system it works.

python-2.7.tcz itself doesn't work, there is an 'Invalid installation' error message. Installing python-2.7-dev.tcz it is fine, so separation must be fine tuned.

[bmarkus]

I think that python should always have a version number, even the main one, given it's upgrade and compatibility nature.

Sounds good. Adding Python 3.x fits to it too. However it may cause confusion for users not knowing which Python version to install at first. Not a big issue, as Python itself is not loaded directly but by other extensions, like pygtk.tcz but still...

[bmarkus]

Submitted pyusb.tcz It is not listed in any .dep files, so can go to the repo just now.

urwid.tcz also submitted which is used only by WICD.

Next step would be to rebuild the most commonly used pygtk and its python dependencies, pycairo, ...

[Jason W]

I will repackage python tonight, I think I remember what caused the invalid installation thing, as well as I will deal differently with the files.

[bmarkus]

Anyway in this test period should I rebuild some of the extensions I mantain?

For sure. All

[jls]

and how should I call them?

[bmarkus]

and how should I call them?

As we are going to update Python moving from 2.6 to 2.7 not keeping different versions paralel only one, keep current name, like pygtk.tcz just rebuild against Python 2.7

[Arslan S.]

I will repackage python tonight, I think I remember what caused the invalid installation thing, as well as I will deal differently with the files.

python-2.7 tce.installed script is just missing flags: "-C /"
as a result files.tar.gz contents are being extracted to the current directory

[bmarkus]

I do not aee why files.tar.gz is needed, its content can be moved to the extension as other files.

[Arslan S.]

when the extension is mounted the actual place of python is /tmp/tcloop/python*
as a result python thinks that its home is /tmp/tcloop/python*/usr/local/lib/python*

maybe a simple patch may fix this issue instead of copying python to root file system

[bmarkus]

Thanks for the info. In this case better to keep it and make sure it is extracted /added properly instead of patching code.

[Jason W]

I was in a rush last night to package python and deal with the extensions that were backing up in the queue, so I made a couple of omissions.  I will fix it tonight.  

Though a patch could be done to make python use use /usr/local/..  instead of /tmp/tcloop/usr/local/.. as its path when invoked as a symlink in /usr/local, the files are small and can be just copied to the filesystem.  I used a tar.gz so this extension would overwrite any /usr/local/bin/python symlink, but a force copy from somewhere else would work too.

With pygtk, pygobject, pycairo,  since it has so many dependent apps, perhaps the Debian way of including both the files in /usr/local/lib/python2.6 and /usr/local/lib/python2.7 would be best for this one extension so the repo doesn't either get broken by the update, or there be the managing of numerous extensions put on hold waiting for them to all be built, and in the meantime hoping no one submits a package built against the current pygtk.  

[Arslan S.]

installing both python-2.6 and python-2.7 side by side but python executable conflicts

to me there are three ways to go

1) force rebuild of all python extensions

2) append python2.7 suffix to new python extensions temporarily such as:
pygtk-python2.7
pyqt-python2.7

3)rename python to python-2.6 and adjust all dep files
python --> python-2.6
and all other python dependent extensions
pygtk-python2.6
pyqt-python2.6

I think the second one is the easiest and less painful way

[Jason W]

One reason I used a tar.gz of the binaries was to force an overwrite of an existing /usr/local/bin/python symlink.  Since 2.7 will be our main python, it should claim the /usr/local/bin/python symlink and not be overwritten when python 2.6 is installed. 

Python versions are of course designed to coexist with one another, the main one claiming the python symlink.  There is actually a "make altinstall" option when installing python as the non-main version that will not disturb an existing /usr/local/bin/python symlink if it is present in the system. 
 
As we will be doing this again one day in the near future, the more I think option 2 would be a way to go even more than including both python directories in each extension as one would not have to build for both versions at any time on any one package.  Once a package is made, it remains and does not have to be repackaged in the future upon another python update, or even renamed.   There will be some overlapping of the same files outside of /usr/local/lib/'python2.x/site-packages, but those are the same files and would be harmless.  I think there may be a variable used to install those files in a manner that would not conflict with another build of the same package like pygtk.  I will look more into it tonight, I may have misread.

To have to rebuild the entire python related part of the repo would be a huge undertaking, but if we use the numbering approach it can be done gradually, with the old python versions being slowly phased out.