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 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 im Speziellen und Diskussionen in kommerziell orientierten Open-Source-Projekten im Allgemeinen.