Blog & actualités

En septembre 2016, Isogeo a publié la première version stable de son plugin pour QGIS, rejoignant ainsi la grande famille des plugins et widgets Isogeo destinés à récompenser le travail de catalogage en valorisant les données géographiques.  

On l’aura compris, étant donné la date de sa publication, le plugin Isogeo a initialement été développé pour QGIS 2. L’objectif de cet article est de vous faire part d'un retour d’expérience concernant le portage du plugin Isogeo vers QGIS 3 effectué par Julien Moura et moi-même.

 

© Simon Sampère

© Simon Sampère

Contexte

En février 2019, QGIS 3.4.5 devient la version de référence de votre logiciel SIG open source préféré. Les utilisateurs du plugin QGIS Isogeo doivent pouvoir accéder à ses fonctionnalités dans la dernière version de leur logiciel de SIG, à plus forte raison quand elle dispose d’autant de nouvelles fonctionnalités. Ce besoin de portage du plugin vers QGIS 3 a donné lieu à une offre de stage, confirmant une nouvelle fois l’implication d’Isogeo dans le milieu universitaire (le développement de la première version du plugin avait déjà fait l’objet d’un stage). J’ai ainsi eu l’opportunité, dans le cadre de mon stage de fin d’étude, de travailler au développement de la nouvelle version du plugin Isogeo compatible avec QGIS 3. 

Grâce au travail de conception réalisé au cours du développement de sa première version, le plugin QGIS Isogeo était fonctionnellement satisfaisant. Il n’était donc pas nécessaire, dans un premier temps, de modifier son interface graphique ou d’ajouter des fonctionnalités. L’objectif prioritaire était d’effectuer une mise en compatibilité isofonctionnelle avec QGIS 3. Les améliorations et les nouveautés de QGIS 3 ont coïncidé avec des changements dans le code source du logiciel. Conséquence de cela : l'incompatibilité des plugins développés en Python pour QGIS 2.x avec QGIS 3.x. Au vu de la quantité de modifications à apporter au code source pour effectuer le portage vers QGIS 3, nous aurions pu décider de développer la nouvelle version du plugin en repartant de zéro. Néanmoins, pour des raisons de temps, compétences et qualité de l’existant, nous avons décidé de partir du code source existant plutôt que de redévelopper from scratch

L’importance des préliminaires

Formation en mode sandbox

Avant de me lancer dans le développement du plugin Isogeo pour QGIS 3, j’ai passé plusieurs semaines à travailler sur un projet sandbox pour me former aux technologies et aux méthodes qu’il me faudrait employer. Cela m'a permis de me familiariser avec :

  • les requêtes à l’API Isogeo et le développement d’interfaces graphiques en Python ;
  • l’utilisation de Git et de GitHub pour l’organisation du travail et la contribution au projet ;
  • les méthodes de développement interne à Isogeo (Kanban).

Étude de l’existant

Une fois les bases techniques et méthodologiques acquises, plusieurs semaines ont été consacrées à l’étude du code source du plugin QGIS Isogeo. Cela m'a permis de :

  • découvrir PyQGIS et PyQt à travers leur utilisation dans le plugin ;
  • comprendre le fonctionnement du plugin, l’architecture de son code et son algorithme ;
  • rédiger une documentation technique qui m'a ensuite servi de référence lors de la manipulation du code.

Collecter les sources d’information

Cette phase d’étude préalable a également été l’occasion de constituer une forme de sitographie contenant un ensemble de ressources en ligne potentiellement utiles lors du développement :

Prendre le temps d’effectuer ce travail préliminaire de formation et d’étude de l’existant a permis de gagner du temps sur le développement à proprement parlé.

Le portage vers QGIS 3

Une triple transition

Comme on peut le lire ici, ce portage impliquait de modifier le code source afin d’opérer la transition de :

  • Python 2 vers Python 3 ;
  • PyQGIS 2 vers PyQGIS 3 ;
  • PyQt 4 vers PyQt 5.

Python est le langage dans lequel sont développées les extensions QGIS. PyQGIS est la librairie Python permettant d’accéder aux fonctionnalités du logiciel et PyQt la librairie Python utilisée pour gérer l’interface graphique du plugin. Certains modules et certaines méthodes de ces librairies ont été remplacés, renommés ou déplacés lors de la montée de version.

Au cours de l’étude du code source, j’ai dressé la liste de tous les modules utilisés dans le code provenant de ces deux librairies. Consulter les ressources en ligne citées précédemment m'a permis d’apporter au code une partie des modifications rendues nécessaires par le passage à la nouvelle version de la librairie. 

Confronter le plugin à QGIS 3 

Une fois que ces modifications facilement déductibles des ressources en ligne ont été effectuées, il fallait essayer d’utiliser le plugin dans QGIS 3  pour identifier les corrections à effectuer pour atteindre la compatibilité. Avant même de lancer le plugin, il faut l’activer dans le gestionnaire des extensions. Le code source est alors inspecté par le logiciel qui vérifie qu’aucun module obsolète (de PyQt 4 ou de PyQGIS 2) n’est sollicité dans le code source. S’il en reste, un message d’erreur permet de les identifier et il faut apporter les modifications nécessaires jusqu’à ce que le code source soit considéré comme celui d’un plugin potentiellement compatible avec cette version du logiciel. 

Une fois le plugin activé, il faut le lancer et l’utiliser, toujours pour identifier les corrections qui n’ont pu être déduites de la lecture des documentations en ligne. J’ai traité les fonctionnalités les unes après les autres, de même pour les messages d’erreur.s avec l’objectif d’aboutir à un comportement identique du plugin dans QGIS 3 et QGIS 2

Juste à temps pour les GeoData Days 2019

Les ressources en ligne permettent d’anticiper une partie des corrections à effectuer mais certaines sont plus faciles à identifier en testant le plugin. Les erreurs alors signalées par le logiciel peuvent simplement provenir du renommage d’une méthode entre la version antérieure d’une librairie et la nouvelle. Parfois la cause est plus complexe car le module impliqué a été réorganisé en profondeur ou remplacé par un autre. Dans ce cas, la correction peut prendre plus de temps. Il est nécessaire de lire attentivement la documentation en ligne et de bien comprendre le fonctionnement de la partie de code concernée afin que la modification apportée n’impacte pas le comportement du plugin. Lorsqu’une erreur liée à une opération en particulier est identifiée, la correction est apportée à chaque morceau de code concerné.

Le portage du plugin Isogeo avançait assez rapidement pour en publier une première version (2.0.0-alpha1) partiellement compatible avec QGIS 3 le 1er juillet 2019 pour les GeoData Days 2019

Le refactoring 

Nous avons poursuivi le portage après les GeoData Days tout en commençant à procéder au refactoring du code source. Cela consiste à remanier le code sans modifier le comportement du plugin. Initialement, la grande majorité du fonctionnement du plugin était assurée par un seul script. Le portage était l’occasion de l’éclater en plusieurs scripts plus petits (modules), chacun en charge d’une ou de plusieurs fonctionnalité.s.

L’objectif de l’opération est de simplifier la compréhension et la maintenance du code en changeant son organisation. Il s’agissait d’isoler les blocs fonctionnels dans des modules qui interagissent entre eux, tout en restant indépendants les uns des autres. Cela permet de faciliter l’identification de l’origine d’un bug et de restreindre ses conséquences sur le fonctionnement du plugin en les limitant à la fonctionnalité concernée. Une organisation fonctionnelle du code le rend également plus accessible et donc transmissible entre développeurs. Effectuer ce passage d’une architecture “monolithique” à une architecture “modulaire” implique de modifier le code en profondeur, afin de permettre l’interaction entre les nouveaux modules. De même que pour le portage, le refactoring a été effectué fonctionnalité par fonctionnalité. Des tests d’utilisation de la fonctionnalité concernée ont été réalisés après la création de chaque nouveau module, afin de vérifier que le comportement du plugin n’avait pas été impacté. Ce processus de vérification a été facilité par la participation de bêta-testeurs issues de trois structures utilisant la solution Isogeo :

Entre le 1er juillet et le 23 octobre 2019, trois versions bêta du plugin Isogeo pour QGIS 3 furent publiées dans le cadre du portage et du refactoring. Cela nous a permis de corriger des bugs et de réorganiser le code source. La première version stable (3.0.0) est sortie le 23 octobre 2019. C’est le résultat de plusieurs mois de développement, aboutissant à un plugin compatible avec QGIS 3.

"Tu sais c’est pas si facile…

… quand QGIS crashe"

Comme nous l’avons dit, le portage a été effectué une fonctionnalité après l’autre. Après chaque modification apportée au code, le plugin était testé dans QGIS 3 pour vérifier que ces modifications menaient au comportement attendu. Lors de cette étape de vérification, quel que soit le morceau de code modifié, on s’attend à deux éventualités :

  • le logiciel signal une erreur causée par la modification ;
  • la modification a fonctionné et le logiciel signale une erreur causée par une autre partie du code.

Dans la plupart des cas, il suffit donc de corriger le morceau de code indiqué par le message d'erreur de QGIS avant de passer à l'erreur suivante. Il n'est pas toujours facile de savoir quelle correction apporter mais le logiciel indique au moins la partie de code à corriger.

Lors de la mise en compatibilité du morceau de code responsable des échanges avec l’API Isogeo, une troisième éventualité se produit : un crash de QGIS au lancement du plugin. Après quelques tests, il est apparu évident que l'origine du crash était l’exécution du code source du plugin Isogeo. Cependant, aucun message d’erreur n’indiquait la partie du code concernée. Cette troisième éventualité constituait donc une difficulté technique complexe à surmonter. Elle a donné lieu à plusieurs jours de développement, destinés à exclure les causes potentielles du bug entraînant le crash de QGIS. L’objectif était d’obtenir les informations qui auraient été fournies par le logiciel via un message d’erreur s’il n'avait cessé de fonctionner dès le lancement du plugin.

… quand ça marche sur QGIS 3.4 mais pas sur QGIS 3.6

Au cours du refactoring du code source, un des tests effectués par un de nos bêta-testeurs (en l'occurrence par un utilisateur du SMAVD) permis de constater que le plugin Isogeo ne fonctionnait pas dans QGIS 3.8. Tout au long du développement, le plugin était testé sur QGIS 3.4 (la version LTR à ce moment-là) en partant du principe que le code fonctionnerait sur les autres versions mineures (3.x), comme indiqué dans la documentation en ligne de l’API QGIS.

Il arrive parfois que cette règle ne soit pas respectée et que les développeurs de l’API de QGIS aient besoin de faire évoluer un de ses modules au point d’engendrer une incompatibilité entre deux versions mineures. Comparer les documentations en ligne de l’API QGIS 3.4 et 3.6 a permis de remarquer qu’un module utilisé dans le plugin (pour gérer les échanges avec l’API Isogeo) a été modifié entre ces deux versions mineures. L’utilisation de ce module dans le code source permet au plugin d’échanger avec l’API Isogeo dans QGIS 3.4 mais pas dans QGIS 3.6 ou supérieur. Après avoir identifié l’origine de cet imprévu, il a fallu modifier l’utilisation du module concerné de manière à faire fonctionner le plugin Isogeo dans toutes les versions de QGIS supérieures ou égales à 3.4.

Ces obstacles difficiles à prévoir peuvent donner lieu à une forme d’agacement assez prononcée lorsqu’ils surviennent. Avec un peu de recul on arrive à se convaincre qu’ils font le charme des technologies opensource comme QGIS.

… quand ça marche chez toi mais pas chez les autres"

Un des intérêts de faire appel à des bêta-testeurs tient au fait de confronter le plugin à un environnement différent de celui dans lequel il est développé. Il n’est pas aisé d’anticiper les dysfonctionnements pouvant être causés par une spécificité de l’environnement de l’utilisateur. Ainsi, les bêta-tests ont mis en évidence la nécessité d'améliorer le comportement du plugin lorsqu’un proxy est utilisé pour la connexion Internet. Les échanges avec l'API Isogeo peuvent être bloqués par différentes configurations de proxy qu'il n'est pas aisé de simuler. Il ne s’agissait pas de prendre en compte la multitude de configurations possibles puisqu'un des prérequis indique que la connexion à l'API Isogeo doit être configurée. En revanche, il est préférable que la présence d'un proxy n'entraîne pas un bug du plugin et qu'il soit capable d'indiquer à l'utilisateur qu'un des prérequis n'est pas respecté.

L’implication des utilisateurs en tant que bêta-testeurs a donc été fondamentale dans le développement du plugin Isogeo pour QGIS 3 et a grandement participé à l’amélioration de son code source.

 

Conclusion

Plusieurs mois de développement ont été nécessaires à Julien Moura et moi même pour effectuer le portage du plugin Isogeo vers QGIS 3. En plus d'être compatible avec la dernière version de votre logiciel open source préféré, son code a été remanié et il est prêt à accueillir les nouvelles fonctionnalités prévues pour les prochaines versions. Avec un peu de recul, certains éléments semblent avoir été déterminants dans la réussite de ce projet :

 

Easy access to Geodata!


Voir aussi :

Article suivant :
Bienvenue Carlo

Simon Sampère
Après une licence de Géographie, je poursuis mes études en cartographie et géomatique (master Carthagéo). Isogeo m'a donné l'opportunité d'approfondir ma formation en développement informatique au cours d'un stage de fin d'étude avant de m'embaucher comme développeur Python. Contribuer à la solution Isogeo me permet de concilier intérêt pour la géomatique et attrait pour la technique en mettant mes compétences au service de l'accessibilité de l'information géographique.