Développer un plugin Isogeo sur QGIS : un retour d’expérience (partie 2/2)

Voici la suite et fin de notre retour d’expérience sur le développement d’un plugin Isogeo sur QGIS (pour rappel, la partie 1).

Développer sur QGIS : un plaisir sans cesse renouvelé

Pour information, mon développement ayant débuté en mai 2016, la version LTR de QGIS était alors la version 2.8 (c’est la 2.14.x depuis). Le plugin devait donc supporter cette version et toutes les versions postérieures. Le développement et la publication de plugins sur QGIS sont ouverts à tous et très facile. En témoignent les 507 plugins répertoriés officiellement comme stables à date !

Cela dit, développer un plugin pour QGIS n’est pas toujours de tout repos, surtout sur/pour Windows ! Retours d’expérience.

Grands et petits plaisirs

Source : les joies du code

La modularité dans l’ADN du logiciel

A l’instar de logiciels grands publics tels que les Firefox ou Chrome dans la famille des navigateurs, QGIS est un logiciel construit pour les extensions. Le socle technique illustre parfaitement ce choix fondateur de la modularité : la plus grande partie du cœur du logiciel, y compris les interfaces graphiques intégrées, sont exposées via une API ouverte.

C’est clairement un confort pour le développeur tiers qui accède ainsi à un vaste éventail de fonctionnalités et de widgets graphiques déjà en place, épargnant des pans de développement répétitifs et potentiellement ardus : gestion des systèmes de coordonnées et de la reprojection à la volée, interfaces de choix d’une couche ou d’un attribut dans une couche, méthodes d’ajout de données vectorielles, rasters et web à la carte (canevas cartographique)… impossible de lister ici les centaines de possibilités offertes sur le buffet de QGIS !

Au-delà du socle technique, c’est aussi la chaîne de publication qui est appréciable. Déclarer, publier et mettre à jour un plugin se fait vraiment avec le minimum de “frictions”.

Et puis, n’oublions pas qu’Isogeo aussi a fait le choix de la modularité pour son offre ! C’est toujours un point commun de plus ;).

Une des références

Littérature existante

L’autre grand avantage est clairement l’importance des ressources sur le développement dans QGIS :

  • la documentation utilisateur, traduite en bonne partie en français ;
  • la documentation de l’API et les recettes de sa prise en main ;
  • les livres imprimés ou numériques ;
  • le fourmillement d’articles de blogs ;
  • les innombrables forums et les questions / réponses ;

Bref, de quoi se sentir moins seul face à une difficulté !

Réactivité des membres actifs du projet

C’est quelque chose de surprenant tant la réactivité des personnes travaillant activement sur le projet QGIS est bonne. Elle se retrouve à plusieurs moments lorsque l’on développe un plugin :

  • lors de la publication d’une nouvelle version, la validation manuelle intervient généralement en moins d’une semaine ;
  • lors du signalement d’anomalies qui ont systématiquement une réponse, même s’il vaut mieux prendre le temps de bien les rédiger et à qui les adresser.

C’est d’ailleurs un bon indicateur de la vitalité de l’écosystème dans lequel on investit en développant dessus. Garantie non négligeable de la pérennité de ce que l’on fait.

Esprit et sentiment de contribuer

Enfin, c’est moins quantifiable en termes de gains, mais il y a une vraie satisfaction personnelle et professionnelle dans le fait de contribuer à un écosystème ouvert et libre, surtout compatible avec un modèle économique viable.

L’occasion de redire ici que l’open source n’est pas gratuit et que si vous utilisez QGIS, notamment de façon industrielle dans un organisme ou entreprise, envisagez sérieusement les moyens de contribuer d’une manière ou d’une autre (soutien financier, signalement d’anomalies, ou aide à la traduction de la doc). Ça ré-équilibrera le ratio français utilisation / contribution ;)


Quelques légères contraintes, pour stimuler la créativité

Python 2.7.5

Certainement pour des raisons de packaging et d’isolement, QGIS embarque sa propre version de Python, indépendante donc de celle/s installée/s par ailleurs sur le poste. Fort heureusement d’ailleurs, si ce n’est que la version de Python embarquée par QGIS est la version 2.7.5 (mai 2013) contre 2.7.12 actuellement.

Cela implique de travailler avec des modules qui ne sont plus à jour, dont certaines fonctionnalités utiles ne sont apparues que plus tardivement. Par exemple, urllib2 aurait pu convenir pour dialoguer avec l’API Isogeo, mais la méthode permettant de définir le certificat SSL manuellement n’est apparue que dans la version 2.7.9 de Python. Ce n’est qu’un exemple parmi d’autres, mais cette question des versions de Python est une contrainte à prendre en compte.

Usage limité ou fragile des modules Python tiers

Également liée en partie à la version de Python embarquée, l’impossibilité d’installer des modules tiers selon le fonctionnement standard du langage (du moins à partir de la version 2.7.10), pourtant l’une de ses forces. Des solutions de contournement plus ou moins complexes existent bien sûr, mais ne sont pas envisageables :

  • soit parce qu’elles exigent une intervention de l’utilisateur final, anéantissant la facilité d’installation, multipliant les frictions et les problèmes de montée de mise à jour ;
  • soit parce qu’elles demandent trop de temps à maîtriser pour garantir un niveau acceptable de maintenabilité ;

Le python de QGIS n’étant pas le même que celui de l’ordinateur, on ne peut pas installer les modules tiers selon la méthode standard. Il faut  passer par un protocole relativement complexe, qui est décrit ici par exemple.

Je pensais pouvoir m’appuyer sur le module développé par Julien Moura pour communiquer facilement avec l’API Isogeo mais il est dépendant de requests (et d’arrow à l’époque), non inclus dans QGIS… avant la version 2.16 ! Ce qui pose aussi la question de la gestion des dépendances aux versions des modules inclus, celles-ci changeant sans qu’il n’y ait vraiment de prévenance sinon d’information transparente (sauf à suivre les modifications du code source de QGIS…).

TOP 3 des problèmes à deux doigts de gâcher le plaisir

Au-delà des contraintes, il y a ces problèmes dont la récurrence nuit à la durée de vie du développeur.

1. La compilation des fichiers d’interface et de ressource

Pour créer facilement l’interface d’un plugin, il est préférable d’utiliser Qt Designer, embarqué avec QGIS. Cet outil permet de créer les fichiers d’interface graphique (*.ui) et de ressources (*.qrc) via… une interface graphique justement, économisant quelques heures de code fastidieux. De plus, les widgets spécifiques à QGIS y sont intégrés (préfixés Qgs), par exemple la liste déroulante listant automatiquement les couches actives.

Ces fichiers d’interfaces et de ressources doivent être compilés. Et c’est là que le bât blesse.

“No module named resources_rc”

Lorsque les ressources graphiques de l’interface (icônes, images…) sont modifiées, Qt Designer ajoute systématiquement une ligne problématique dans le fichier d’interface ui. Ainsi, la balise <resources/> est remplacée par le bloc suivant :

<resources>
  <include location="../resources.qrc"/>
</resources>

Cette modification provoque une erreur au moment du chargement du plugin et donc pendant le chargement de QGIS : Import error : No module named resources_rc”.

Il faut donc modifier manuellement les fichiers d’interface (*.ui) pour remettre la ligne dans son état précédent, et ce, à chaque modification de l’interface dans Qt Designer.

Les widgets personnalisés de QGIS “qgis.gui”

Dans la même veine, l’utilisation des widgets personnalisés de QGIS n’est pas gérée correctement par Qt Designer. Ainsi une ligne doit systématiquement être changée à la main après chaque enregistrement du fichier d’interface dans Designer. Exemple avec le cas d’une zone repliable, utilisée pour permettre à l’utilisateur de masquer les filtres complémentaires et dont le nom de classe est QgsCollapsibleGroupBox :

<class>QgsCollapsibleGroupBox</class>
  <extends>QGroupBox</extends>
<header>qgscollapsiblegroupbox.h</header>

Il faudra alors remplacer le contenu de la balise header par “qgis.gui”.

Si devoir compiler les fichiers d’interface pouvait paraître une légère contrainte, devoir modifier à la main l’import des ressources, puis  le header des QGIS widgets, pour ensuite pouvoir compiler devient rapidement agaçant !

Pour limiter l’effet énervant de ces problèmes et éviter qu’ils ne se retrouvent dans une version distribuée du plugin, Julien a créé un script chargé du nettoyage automatique (et de la création de l’archive zip à mettre en ligne).

2. Les incohérences dans PyQGIS

La documentation souvent incomplète de l’API QGIS, pour laquelle les exemples sont nombreux mais rarement avancés ou exhaustifs, fait souvent passer à côté des possibilités réellement offertes. Par exemple, pour ajouter une vue PostgreSQL ou  la gestion des styles des couches WMS.

Plus étonnant, les syntaxes utilisées pour ajouter des couches, en particulier à partir de services géographiques. Quand il s’agit d’un WMS il faut fournir une URL sous une forme encodée et le nom du fournisseur en minuscule. Quand il s’agit d’un WFS, il faut fournir une URL “normale” et le nom du fournisseur doit être en majuscule. Ah et pour un WMTS, le nom du fournisseur est aussi wms et non wmts…

Dans ces cas-là, l’écart entre les fonctionnalités intégrées à QGIS et celles exposées via l’API se creuse. Là où l’ajout d’une couche d’un service via l’interface de QGIS passe par la récupération et l’interprétation du GetCapabilities, PyQGIS ne permet pas de réaliser ces opérations sans implémenter par soi-même la requête et le parsing ou utiliser un module tiers (OWSLib ou GDAL en l’occurrence), créant ainsi une dépendance supplémentaire à maintenir.

3. Les nombreuses petites erreurs cachées dans PyQGIS

Mais le vrai plaisir de développer sous QGIS c’est avant tout les petites erreurs inattendues. Sans prétendre dresser une liste à rallonge, voici les deux dernières en date auxquelles j’ai pu me confronter. Dans les QSettings (paramètres de QGIS), certaines valeurs qui devraient être des booléens sont en réalité des chaînes de caractère. Les QSettings vous renvoient donc parfois le texte “false” au lieu du booléen python False. De même pour les signets, auxquels on peut accéder via PyQGIS, mais dont le système de coordonnée est donné par un code interne à la base de donnée de QGIS, et non par un code ESPG. Le code obtenu est donc inutilisable.

QGIS regorge de petites erreurs de ce type, qui passent inaperçues dans un premier temps, jusqu’au moment où l’on se rend compte que notre code renvoie des résultats incohérents. Il faut alors éplucher chaque ligne jusqu’à se rendre compte que l’API de QGIS comporte une petite coquille.

Mais se lancer dans le développement sur l’API de QGIS, remarquer des dysfonctionnements et les rapporter afin qu’ils puissent être corrigés, c’est aussi ça participer à l’aventure de ce logiciel libre et collaboratif !

Conclusion

Malgré les quelques difficultés, le plugin a été fini dans les temps, atteignant et dépassant ses attentes initiales.

Pour aller plus loin :

Soyez le premier à commenter

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Unable to load the Are You a Human PlayThru™. Please contact the site owner to report the problem.