#187 migration to QT API2 (new-style signals)

[Frédéric PICCA]

Hello,

I uploaded spyder 2.3.6 into Debian unstable and then I discovered that it breaks all its reverse dependencies. Due to the support of the jupyther >= 4.0.0. They migrate from QT API 1 to API 2 by default.

so for now application using pyQT4 and spyderlib are broken with this version.

hopefully, Pierre Raybault, is preparing guidata, guiqwt and the brand new python-qwt whicih support pyQT5.

to summerize:

Debian testing is ok (I blocked the migration of spyderlib 2.3.6

It is time to migrate your applications to API #2 by default, in order to prepare the pyQT5 migration.

I am preparing in Debian experimental a working stack (guidata, guiqwt, python-qwt, spyderlib) in order to switch to APi #2 by default with the Help of Pierre Raybault.

Cheers

Frederic.

PS: It should be nice to discuss about this during your workshop ;). It's quit eurgent now to take decision in order to prepare the next release.

[Carlos Pascual]

Can you clarify?
If I understand correctly, this only affects to those parts of taurus which import spyderlib (i.e. essentially tauruseditor), right?

I mean: it does not force us to migrate all our old-style signals to new-style right now, right?

Note: it is something that we want to do soon, but at ALBA we still need to worry about PyQt4.4 compatibility (not for long, I hope)

[Frédéric PICCA]

Hello,

If you look at the code of spyder 2.3.6 you will see that is contain already old and new-syle signals. So it depends of the widget you are using. BUT the next guiqwt and guidata have already made the migration to the new-style.

For the API #2. here the code used in spyderlib.

The same code will be added into guiqwt, guidata and python-qwt, in order to be compatible with pyqt5.

here the new default:
if API == 'pyqt':
# Since Spyder 2.3.6 we only support API #2
import sip
try:
sip.setapi('QString', 2)
sip.setapi('QVariant', 2)
sip.setapi('QDate', 2)
sip.setapi('QDateTime', 2)
sip.setapi('QTextStream', 2)
sip.setapi('QTime', 2)
sip.setapi('QUrl', 2)
except AttributeError:
pass

try:
    from PyQt4.QtCore import PYQT_VERSION_STR as __version__
except ImportError:
    # Switching to PySide
    API = os.environ['QT_API'] = 'pyside'
    API_NAME = 'PySide'
else:
    is_old_pyqt = __version__.startswith(('4.4', '4.5', '4.6', '4.7'))
    is_pyqt46 = __version__.startswith('4.6')
    import sip
    try:
        API_NAME += (" (API v%d)" % sip.getapi('QString'))
    except AttributeError:
        pass

cheers

[Frédéric PICCA]

Hello, I just want to ping in order to know if there is some news from your side about this transition.
The upstream of guiqwt has done a great job, migrating from PyQwt to a pure python implementation PythonQwt. But in the same time, he got rid of the #API1 in order to support PyQt5.

Idem for the spyder guyes.

Can you give me your plan and dates if possible, In order for me to decide how to manage the integration of taurus in Debian. The next freeze will be around Octobre of November 2016.
so I need to have something at least properly integrated before June. (I do not count the summer holidays ;).

thanks for your help

Frederic

[Carlos Pascual]

Hi,

We are currently focused in getting a taurus4 "preview" branch published
(deadline: next week).

This branch will eventually be merged into develop (my aim is that in
the Jan16 release we can release the last 3.x, together with a 4.x
beta), and that the merge of taurus4 into develop should occur just
then.

This is relevant to your question because, taurus4 will (among many
other things) raise the PyQt dependency from 4.4 to ~4.8), thus removing
our main obstacle for doing the API1->API2 transition.

This means that there won't be technical obstacles for working on #187
starting from January (or even from next week, if one wants to use the
taurus4 preview).

I would love to get an offer from someone outside Alba who wants to
propose the patches (if no ones comes up, I will try to squeeze it in
our dev plans, during first half of 2016).

I hope this helps for your planning.

Cheers,

Carlos

[Frédéric PICCA]

Hallo Carlos,

thanks a lot for sharing these informations.

Now I am quite confidant that we will have a fully fonctional sardana stack in the next Debian stable. the only difficult point will be ipython/Jupyter4.

so for now I will block the migration of spyder into testing in order to avoid the breakage of your sardana stackuntil this ipython/jupyter things is resolved.

I can now confidently upload the new guiqwt stack into unstable for testing by other projects and let it migrate into testing once taurus4 is released.

once again thanks

Frederic

[Carlos Pascual]

Migrating the old-style signals to new-style manually is painful and error-prone.

I found a script that helps in automating this (it uses the lib2to3 module):
https://github.com/qgis/QGIS/blob/master/scripts/qgis_fixes/fix_signals.py

To use it, see this:
http://stackoverflow.com/questions/24508357/how-to-launch-own-2to3-fixer

I just "packaged" it in the attached tgz.
BUT note that whie it converts the "emit" and "connect" calls, it does not create the custom signals using the pyqtSignal (and therefore the resulting code still needs manual edition if custom signals are used)

[Frédéric PICCA]

Just for information,

python-qtpy was uploaded into Debian (if it can help...)

[Carlos Pascual]

Thanks for that!
qtpy is indeed very helpful, but it requires that your code is using new-style signals (hence the need for translation)

[Carlos Pascual]

I adapted the auto-conversion script to work on the Taurus code. See;
https://github.com/cpascual/fixsignals

It can be used as a first approach.

It is also convenient to run the following prior to the conversion in order to gather info which may be useful later on:

# Find all ussages of emit, connect and disconnect:
~/src/taurus$ egrep -Irn '\.emit\(' lib > all_emit
~/src/taurus$ egrep -Irn '\.connect\(' lib > all_connect
~/src/taurus$ egrep -Irn '\.disconnect\(' lib > all_disconnect

[Carlos Pascual]

Since the people from MAX IV offered help on this (thanks!), I think it is interesting to have a public place to push the work to in order to collaborate. So I pushed the result of running the fixsignals script to
https://sourceforge.net/u/cmft/ctgensoft-taurus/ci/bug-187/tree/

(write access to this can be granted to anyone working on this bug)

PS: If you feel more comfortable using a fork on github for pushing and discussing this issue, it is also fine for me

[Carlos Pascual]

Just to keep some update: the efforts of MAXIV and Alba on this are being coordinated in https://github.com/cpascual/taurus/pull/5

[Carlos Pascual]

Fixed in develop [054a9d]. See detailed discussion and history in https://github.com/cpascual/taurus/pull/5 .

Thanks to everyone involved for the good work!