[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