QGIS-Plugins werden primär in Python geschrieben. Sie sind dadurch Python-Module, jedoch keine Python-Pakete, und fallen dadurch – unnötigerweise – weit hinter die heutigen Möglichkeiten des Python-Ökosystems zurück. QGIS-Plugins könnten mehr, wenn man sie ließe, doch dies wirft einige technische Fragen auf. Meine Analysen und eine mögliche Antwort dokumentierte ich Mai 2020 in QEP 179. Dies ist ein Erfahrungsbericht über die bis heute andauernde Diskussion, die darauf folgte.
Python ist im Moment eine der wohl populärsten Programmiersprachen, die es gibt. Obwohl sie als dynamisch typisierte und interpretierte Sprache durchaus kontrovers diskutiert wird, ist ihre signifikante Rolle nicht mehr zu bestreiten. Das Python-Ökosystem bietet Möglichkeiten für faktisch jede technische und wissenschaftliche Disziplin. Python-Pakete sowie entsprechende Werkzeuge sind für das ganze Spektrum an Computern erhältlich, von Embedded-Systemen bis hin zu HPC-Clustern und diversen Hardware-Beschleunigern. Bemerkenswert ist, dass sich die meisten dieser Pakete relativ einfach bedienen lassen und für sich genommen, einmal installiert, relativ geringe Programmierkenntnisse erfordern. Gleichzeitig lässt sich QGIS durch in Python geschriebene Plugins ebenfalls relativ einfach erweitern. Es drängt sich eine eigentlich naheliegende Frage auf: Kann man QGIS mit alldem, was das heutige Python-Ökosystem anbietet, kombinieren? Die Antwort ist „im Prinzip ja“. Unglücklicherweise ist diese Form der Kombination zumeist äußerst komplex und nur technisch versierten Nutzern mit fundierten Kenntnissen über Software-Entwicklung und - Deployment vorbehalten. Die Weitergabe einer entsprechenden fertigen Lösung an dritte ist in den allermeisten Fällen kaum sinnvoll zu bewerkstelligen. Das Problem ist „einfach“ erklärt: QGIS-Plugins benutzen ihr eigenes, sehr eingeschränktes Paket-Format. Explizite Abhängigkeiten zu anderen „reinen“ Python-Paketen sind nicht vorgesehen, genauso wenig wie eine transparente Integration von relevanten Paket-Managern. Dies ließe sich ändern, wobei eine etwaige Änderung jedoch in jedem Fall sehr weitreichende technische Konsequenzen hätte. Die [Diskussion eines etwaigen Lösungsansatzes](https://github.com/qgis/QGIS-Enhancement-Proposals/issues/179) mit den QGIS-Entwicklern hat gezeigt, dass überraschend viel grundlegender Aufklärungsbedarf über relevante Terminologie und betroffenen Technologien besteht. Der durchaus naheliegende Drang, eine möglichst einfache Lösung zu finden, ohne die jeweiligen Konsequenzen vollkommen zu durchdenken, erschwert den Prozess. Dieser Talk ist ein Erfahrungsbericht und -austausch: Über [QEP 179](https://github.com/qgist/pluginmanager-qep/blob/master/QEP.md) im Speziellen und Diskussionen in kommerziell orientierten Open-Source-Projekten im Allgemeinen.