[QGIS-Developer] Migrating plugins
Javier Becerra Elcinto
javier at panoimagen.com
Thu Jan 11 00:44:10 PST 2018
Hi Paolo,
Thanks for the effort of setting up the wiki page, we have started
migrating some plugins and missed some kind of "standard"
guidelines/best practices.
I was not able to find a way to contribute to the wiki, and could not
find an issue/forum associated with it - I do not know much about QGis'
team development workflow, so that there may be resources I am not aware
of (in that case, it might be a good idea to link them from the wiki?).
So I guess this list is the way to go at the moment, I will share my two
cents based on our experience migrating to QGis3 (we have recently made
a pull request to complete the migration of profiletool plugin to QGis3
https://github.com/PANOimagen/profiletool/commit/2631bc4600938d7beeaf6281bcb8de16a6de912c
and are working on other internal plugins):
-We iniatially thought on creating a compatibility layer to allow Qgis2
plugins to run (mostly?) unmodified on QGis3; however that seems like a
bad idea in the long term, and followed the monkey-patching strategy set
forth by opengis.ch in their qgis2compat plugin
(https://github.com/opengisch/qgis2compat). This means, we make all the
code qgis3 compatible, and patch QGis2 on runtime to provide Qgis3 api
compatibility. In the long term, dropping support for QGis2 should be as
simple as removing the apicompat module, the plugin's code would remain
unmodified to keep on running on QGis3.
-Unfortunately qgis2compat has not been updated in the last 10 months,
and we do not want to add an additional dependency to the plugins, so
that we have included their apicompat files as needed and completed the
missing bits we found (e.g. QgsPointXY). We can contribute our additions
to Qgis2compat if someone is interested.
-There are however some modifications that we have not been able to
manage with monkeypatching, for instance
PyQt4.QFileDialog.getOpenFilenames returns a list of files and
PyQt5.QFileDialog.getOpenFilenames returns a tuple with the list of
files and the extensions (i.e. PyQt5.QFileDialog.getOpenFilenames ==
PyQt4.QFileDialog.getOpenFilenamesAndFilter); modifying PyQt4's
behaviour can lead to other plugins, who expect the proper PyQt4 api, to
stop working. We prefer not to introduce 'new' functions (i.e.
PyQtx.QFileDialog.getOpenFilenames5) that would not be neither PyQt4 nor
PyQt5, and the best option we have found is to check PyQt version or use
a try/except to manage compatibility. We do not like it, but it is the
least ugly solution we could find. If someone has a nicer/more
elegant/more pythonic solution we are willing to hear from you :)
Regards,
Javier
El 09/01/2018 a las 11:17, Paolo Cavallini escribió:
> Il 09/01/2018 11:13, Werner Macho ha scritto:
>> Hi Paolo,
>> Good initiative!
>> I will contribute if I find anything important to say. ;)
> Thank you Werner. Any help will be useful, both in writing the guide and
> in testing and streamlining it.
> All the best.
More information about the QGIS-Developer
mailing list