QGIS

QGIS 3.0 - Comment, quand et quoi; ça implique

Beaucoup d'entre nous demandent:

Quand QGIS 3.0 sera-t-il disponible?

L'année dernière (2015), l'équipe du projet a commencé à étudier quand et comment QGIS 3.0 devait être publié. Ils ont promis, d'après un message de Anita Graser, qu'ils allaient clairement transmettre aux utilisateurs et aux développeurs de leurs plans avant de lancer QGIS 3.0. Ils ont récemment essayé de présenter certaines des considérations pour une version de QGIS 3.0 et à la fin de l'article, nous avons l'occasion de présenter nos idées.

Pourquoi 3.0?

QGis_LogoEn règle générale, une version majeure est réservée aux moments où une modification importante est apportée à l'API de votre logiciel. Cette rupture n'est pas une décision anodine pour le projet QGIS puisque nous sommes des centaines de milliers d'utilisateurs qui dépendent de QGIS, à la fois pour notre propre usage et pour des services fournis à des tiers.

De temps en temps casser l'API est nécessaire pour adapter la mise à jour de l'architecture avec des approches améliorées, de nouvelles bibliothèques et des corrections aux décisions prises dans le passé.

Quelles sont les conséquences de la rupture de l'API?

Une raison pour laquelle cette violation de l'API dans QGIS 3.0 est que cela aura un grand impact, ce qui pourrait briser des centaines de plug-ins développés qui ne seraient plus compatibles avec la nouvelle API et les auteurs de ceux-ci doivent faire un examen de leurs développements pour assurer la compatibilité avec la nouvelle API.

L'ampleur des changements nécessaires dépend en grande partie:

  • De nombreuses modifications de l'API affectent la fonctionnalité actuelle.
    Combien de points plugins auteurs ont utilisé des parties de l'API qui changerait.
  • Quels sont les principaux changements à 3.0?

Il y a quatre domaines clés qui sont à la recherche d'un changement à 3.0:

 

Qt4 à jour QT5: Il s'agit de l'ensemble de base de bibliothèques sur lesquelles QGIS est construit au niveau supérieur, nous parlons du niveau fonctionnel CORE de la plate-forme. QT fournit également des bibliothèques pour effectuer la gestion de la mémoire, les opérations de connectivité et la gestion des graphiques. Qt4 (sur lequel QGIS est actuellement basé) n'est actuellement pas développé par les responsables de la bibliothèque Qt et pourrait avoir des problèmes de fonctionnalité avec certaines plates-formes (par exemple OS X) et même faciliter la gestion des versions binaires (par exemple Debian Testing et la prochaine version de Debian "S'étirer"). Le processus d'amener QGIS à QT5 a déjà une avancée importante (principalement ce que Matthias Kuhn a fait) qui, avec Marco Bernasocchi, fume sur le "QField" Android entièrement basé sur QT5. Cependant, il existe certaines limites à la mise en place et au fonctionnement du nouveau QT5 en raison de son impact sur QGIS - en particulier avec les widgets de navigateur Web (principalement utilisés dans Composer et également à quelques autres endroits dans QGIS).

PyQt4 à jour PyQt5: Ce sont les changements relatifs au langage Python pour Qt sur lequel repose l'API QGIS Python. Il est proposé de changer la bibliothèque de QT5 C ++, il est également prévu de déplacer la bibliothèque Python vers PyQt5 afin que les bénéfices de la nouvelle API QT5 dans Python puissent être exploités.
Mise à jour de Python Python 2.7 3 à: Actuellement, tout fonctionne sur Python 2.7. Python 3 est la dernière version de python et est recommandé par ceux qui dirigent ce projet. Python 2 est légèrement incompatible avec Python 3 (presque proportionnel à l'incompatibilité entre QGIS 2 et Qgis 3). De nombreux développeurs ont rendu python Python 3 largement rétrocompatible avec Python 2, mais la compatibilité descendante n'est pas terrible.
L'amélioration QGIS propre API: L'un des problèmes liés au maintien de la compatibilité des API entre les versions est que vous devez vivre avec vos choix de conception sur le long terme. Tous les efforts sont faits dans QGIS pour ne pas casser l'API dans une série de versions mineures. La publication d'une version QGIS pour 3.0 avec une API non prise en charge actuellement nous donnera l'occasion de "faire le ménage" en corrigeant les éléments de l'API avec lesquels nous ne sommes pas conformes. Vous pouvez voir une liste provisoire de 3.0 a proposé des modifications à l'API.

Comment soutenir changer l'API 3.0

Comme déjà mentionné, la version 3.0 rompra avec la version 2.x de QGIS et il est possible que de nombreux plugins, applications existantes et autres codes basés sur l'API actuelle se cassent. Alors, que peut-on faire pour atténuer les changements? Matthias Kuhn, Jürgen Fischer, Nyall Dawson, Martin Dobias et d'autres grands développeurs ont cherché des moyens d'atténuer le nombre de changements de rupture d'API tout en continuant à faire progresser la base de code de QGIS basée sur la prochaine génération de bibliothèques et sa propre API interne. Lors de notre dernière réunion du comité de pilotage du projet QGIS, nous avons géofumé diverses possibilités. Le tableau suivant résume ce que Matthias Kuhn a gracieusement résumé et que nous avons en partie tenté de translittérer dans cet article en fonction de ce que Ils ont publié sur son blog:


QGIS 2.14 LRT
QGIS 2.16 ??? QGIS 3.0
Date de sortie Fin Février 4 2.14 mois ¿Cycle 8 mois?
notes Mise à jour de code de base de python de QGIS python 3 pour être compatible et supporte PyQt5 (application partielle pour la console fonctionnalités clés, par exemple, les extensions principales de python etc.)
Qt4 Si

Obsolète dans Debian extensible (en raison d'une année)

(-webkit éliminé)

Oui Non
Qt5 Non

Misses QWebView - nouveau remplacement pas sur toutes les plateformes. De plus Misses QPainter Engine.

Si Si
PyQt4 Si Si Non
PyQt5 Non Si Si
Python 2 Si Si Non
Python 3 Non Si Si
API nettoyage Non Non Si
Emballages
PyQt5 -> PyQt4
~ 90% offre une compatibilité ascendante
Non Si Si
mainstream binaire Sur la base Qt4 Sur la base Qt4 Sur la base Qt5
La priorité de financement wrappers Python

Il y a deux choses importantes à noter à propos de la proposition Matthias:

Dans la première phaseLe travail se fait dans la série pour compléter 2.x QT5 de support, PyQt5 en utilisant Python 3.0, soutien Qt4, PyQt4 et Python 2.7. Cela implique que toutes les modifications apportées dans la première phase serait compatible avec les versions antérieures 2.x. caractéristiques Python seront incorporées seront introduites afin que l'ancienne API PyQt4 peut encore être utilisé en particulier lors de la compilation contre QT5, PyQt5, Python 3.0. En utilisant QGIS compilés contre Qt4, PyQt4 et Python 2.7 ne serait pas compatible briser.
Dans la deuxième phaseIl travaillerait pour produire QGIS 3.0, l'introduction de la nouvelle API, supprimer complètement le Python 2.7, y compris le soutien pour Qt4 et PyQt4. Les nouvelles fonctionnalités en python entrant dans la première phase sera maintenue, compte tenu de tout le code python et développements pour les versions 2.x de QGIS continuer à travailler sur les versions 3.x de QGIS. Cette phase devrait également introduire des changements dans l'API QGIS qui peut casser certains plugins. Pour remédier à cela fournira la migration aa d'orientation pour tenter de faciliter la migration des versions versions 2.x QGIS 3.x QGIS.

Caveat emptor

Il y a quelques astuces pour vous demander de veiller à ce que la migration vers le son QGIS 3.0 moins douloureux.

  • 1. SIl convient de noter que si l'approche énoncée ci-dessus tente de minimiser la quantité de travail qui existe dans les scripts sur python dans les plugins, ce ne sera pas nécessairement 100%. Il y aura très probablement des cas où le code devra être peaufiné et dans tous les cas au moins, il devra probablement être révisé afin de garantir qu'il continue de fonctionner correctement.
    2. Il n'y a pas de ressources financières officiellement établies pour rémunérer les développeurs qui investissent volontairement leur temps dans ce processus de migration. Pour cette raison, il sera très difficile de donner des délais exacts pour la durée de chaque partie du processus. Cette incertitude doit être prise en compte dans la planification. Les dons sont bien sûr les bienvenus pour y parvenir.
    3. Il peut y avoir des développeurs et des institutions qui financent de nouvelles fonctionnalités pour la série QGIS 2.x et cela peut affecter votre travail. Il est nécessaire d'inclure dans les plans et budgets de ces projets, une certaine allocation pour faire face à la migration vers la plateforme QGIS 3.x.
    4. Si l'équipe QGIS travaille sur un "changement total", il y aura un temps relativement court pendant lequel QGIS sera instable et en constante évolution en raison des mises à jour continues de QGIS 3.0.
    4. Si vous développez de manière « évolutive », vous courez le risque que le développement 3.0 prenne plus de temps à moins que vous n'ayez un groupe fidèle de développeurs qui travaillent dessus et le préparent pour le portage.

    Propositions

À la lumière de toutes les informations ci-dessus, l'un des deux cours d'action sont proposés:

proposition 1:

Sortir une version provisoire 2.16 puis commencer à travailler en priorité sur la version 3.0, avec une fenêtre de développement de 8 mois. Les modifications apportées à la version 2.16 chercheront à être compatibles avec la version 3.0 (voir python3 / pytq5).

proposition 2:

Longe 3.0 une fois avec une fenêtre de durée plus étendue sur QT5, Python 3.0 et PyQt5 et demander aux développeurs de faire leur travail dans 3.0. Continuer avec les versions 2.x avec la fréquence habituelle jusqu'à ce que 3.0 est prêt.

propositions alternatives

Vous avez une proposition alternative? QGIS souhaite connaître les alternatives possibles. Si vous souhaitez soumettre une proposition, veuillez l'envoyer à tim@qgis.org avec le sujet "Proposition QGIS 3.0".

Devrait suivre la Blog QGIS, Où venait cette publication.

Golgi Álvarez

Écrivain, chercheur, spécialiste des modèles de gestion des terres. Il a participé à la conceptualisation et à la mise en œuvre de modèles tels que : Système national d'administration de la propriété SINAP au Honduras, Modèle de gestion des municipalités conjointes au Honduras, Modèle intégré de gestion du cadastre - Registre au Nicaragua, Système d'administration du territoire SAT en Colombie . Éditeur du blog de connaissances Geofumadas depuis 2007 et créateur de l'AulaGEO Academy qui comprend plus de 100 cours sur les sujets SIG - CAD - BIM - Digital Twins.

Articles Relatifs

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont marqués avec *

Retour à bouton en haut