{"id":2074,"date":"2016-05-04T10:50:18","date_gmt":"2016-05-04T08:50:18","guid":{"rendered":"https:\/\/www.opengis.ch\/?p=2074"},"modified":"2020-04-29T16:05:13","modified_gmt":"2020-04-29T14:05:13","slug":"qgis-qt5-and-python3-migration-current-state","status":"publish","type":"post","link":"https:\/\/www.opengis.ch\/de\/2016\/05\/04\/qgis-qt5-and-python3-migration-current-state\/","title":{"rendered":"QGIS: Qt5 and Python3 migration, current state"},"content":{"rendered":"

Behind the scenes a lot has happened to get ready for Qt5 and Python3. On the same codebase that is becoming the next release QGIS 2.16. This is really a great thing since we can focus work on a single master branch and I’m very happy that we got so far with this approach already.<\/p>\n

Testing<\/h2>\n

At OPENGIS.ch we have\u00a0put a huge\u00a0effort into getting the Travis CI test infrastructure to test our code with Qt5 and Python 3. This gives us confidence that we don’t have regressions introduced once we declare Qt5 and Python 3 to be default. At the time of writing we have 177 tests passing on Qt5\/Python3<\/a> vs\u00a0211 tests on Qt4\/Python2<\/a>. Most of the missing tests are caused by a single issue (PyQt5 and NULL, see below).<\/p>\n

Migration tool<\/h2>\n

There is a script 2to3<\/a> that takes care of migrating „old“ python code to portable code. That means, after running this tool on your python code it is compatible with PyQt4, PyQt5, Python2 and Python3.
\nIt uses the future library for python compatibility<\/a> and a custom qgis.PyQt module that takes care of importing from the appropriate PyQt4 or PyQt5 modules.
\nThis can be done on build for core plugins with a new cmake option We do this on our (travis) CI builds when building for Qt5.
\nPlease note that the tool does a very good job (kudos to J\u00fcrgen at this point) but it cannot do everything, so plugin developers will also need to test in-depth and we’ll need to also prepare a migration guide that lists things to manually take care of.<\/p>\n

PyQt5<\/h2>\n

PyQt5 – just like Qt5 – is very similar to PyQt4. This is a good thing since it makes it easier to write portable code.
\nThe main issue which we have found so far is the lack of PyQtNullVariant<\/a> and without this we don’t have proper support for NULL values. Definitely a no-go. Or we use to a different handling of attributes which would mean major manual updates to all plugins, IMHO also a no-go. The good thing is,\u00a0there are good chances that PyQtNullVariant will be re-introduced in PyQt 5.7 but this means that our minimum Qt requirement will be Qt 5.7 which in turn means that older linux distros will be locked into using old QGIS versions.<\/p>\n

Qt5<\/h2>\n

A lot of these updates have been done some time ago already. Qt5 (without python involved) runs quite painless. QField<\/a>\u00a0wouldn’t run without it.<\/p>\n

What’s left to do<\/h2>\n