Ja, willkommen zum dritten Vortrag hier in diesem Kugis-Blog. Ich begrüße Frieda Kessler, Geoinformatik hast du studiert an der Uni Trier, bist jetzt in Düsseldorf gelandet,

beim Geoinformatik-Büro Dassau und machst dort Python-Programmierung und du willst uns heute zeigen, wie wir unser eigenes Kugis-Plugin-Repository betreiben können. Ich freue mich auf deinen Vortrag. Danke schön. Ja genau, also danke für die Einleitung. Genau, das wurde eigentlich

alles schon erwähnt. Ich habe jetzt leider, ich meine Marco hatte gerade so eine schöne Lobeshymne, ich habe keine Lobeshymne, aber kurz zu uns. Wir machen GDI, Open Source, das heißt Plugins

für Kugis, aber auch Web-Anwendungen und alles, was mit Geo-Daten zu tun hat. Mein Vortrag heute hat das Thema, wie mache ich mein eigenes Kugis-Plugin-Repository. Dafür wollte ich euch erstmal fragen, wer von euch hat schon mal ein Kugis-Plugin in Kugis installiert?

Das sind ja schon einige. Wer hat schon mal ein eigenes Kugis-Plugin geschrieben? Das sind auch schon einige. Und wer von euch hat schon mal ein anderes als das offizielle Kugis-Plugin-Repository benutzt, also eingebunden? Das sind auch einige, das ist doch schon mal schön. Gut,

also ich werde so ein bisschen chronologisch durch den ganzen Prozess gehen. Erstmal, warum wir das Ganze angefangen haben. Also ich beschäftige mich mit dem Thema so on off schon seit 2017 tatsächlich, das habe ich jetzt in GitHub gelesen. Ich werde kurz darüber erklären, was ein Kugis-Plugin-Repository ist, also was so die Bausteine davon sind. Und

dann halt chronologisch, wie wir angefangen haben, das alles ein bisschen zu automatisieren, bis hin zu einer Web-Anwendung. Genau, und am Ende, wenn noch Zeit ist, werde ich auch eine kleine Demo zeigen. Genau, also unsere Motivation war, wir wollten unsere Plugins, die wir geschrieben haben, einfach auch den Kundinnen bereitstellen und auch irgendwie die

Möglichkeit haben, dass wir so zu Testzwecken im kleinen Kreis ein Plugin nutzen können. Deswegen haben wir auch später uns dafür entschieden, eine Benutzerverwaltung an das Ganze anzugliedern. Genau, und eigentlich angefangen hat das Ganze mit, ich habe gesehen, man kann ein eigenes Plugin-Repository hinzufügen in Kugis. Wie baut man so was? Genau,

also warum nicht? Einfach mal probieren. Genau, ein Plugin-Repository in Kugis ist eigentlich nichts anderes als eine XML-Datei, wo alle Plugins aufgelistet sind. Das ist quasi das Inhaltsverzeichnis. In der XML-Datei steht dann noch drin, wo dieses Plugin quasi

runtergeladen werden kann. Und genau, dann haltet das Plugin als ZIP-Datei. Genau, und wenn wir dieses, ich habe es jetzt hier mal beispielhaft aufgeführt, wenn wir diese Verzeichnisstruktur jetzt auf den Webserver bereitstellen würden, hätten wir quasi schon unser erstes Plugin-Repository, also ganz einfach XML-Datei tippen, Plugin da reinlegen

und fertig. Die XML-Datei sieht ungefähr so aus. Wer gestern meinen Vortrag gesehen hat, erkennt das Plugin vielleicht wieder. Genau, also da stehen halt so, es gibt einige quasi Tags, die man ersetzen kann, aber das ist jetzt so das Grundlegende. Da steht drin,

wer das Plugin geschrieben hat, welche Kugis-Version, welche Plugin-Version und am wichtigsten die Download-URL, also wo kann ich das runterladen? Genau, und angefangen haben wir dann halt 2017 uns zu überlegen, diese XML-Datei von Hand zu schreiben, das ist doch sehr aufwendig, kann man das sich irgendwie automatisieren. Und in einem Kugis-Plugin,

also einige haben sich auch gemeldet, dass sie schon mal Kugis-Plugins geschrieben haben, da gibt es immer diese Metadata-TXT-Datei und dort sind eigentlich alle Informationen zum Plugin bereits drin, also Name, Version und so weiter. Und deswegen haben wir einfach angefangen, diese XML-Datei zu generieren, indem wir die TXT-Datei, also die Meta-Daten

aus den ZIP-Dateien extrahieren, lesen und quasi automatisch generieren. Hier ist ein kurzer Screenshot von diesem Tool, was ich 2017 geschrieben habe, noch in Python 2 damals. Da gebe ich dann quasi einfach den Ordner an, wo die Plugins liegen und wenn da ein neues

Plugin hinzugefügt wurde in dem Ordner, ein neues Plugin gefunden und dann wurde die XML-Datei neu generiert. Genau, wir hatten damals auch schon eine HTML-Seite quasi, aber das war alles noch sehr statisch. Also Kugis kann ja auch quasi vom Plugin-Repository

nur Plugins in einer bestimmten Version abfragen. Das geht damit nicht, weil wir quasi eine XML-Datei mehr generieren. Genau, und ich muss immer das Skript manuell jedes Mal aufrufen, wenn ich ein Plugin hinzugefügt habe. Also haben wir uns irgendwann entschieden, komm, wir machen eine Web-Anwendung. Das ist dann quasi

unser aktuelles Plugin-Repository, da war es entstanden. Das bietet uns jetzt die Möglichkeit, wir können selber quasi im Webbrowser ein Plugin hochladen, wenn wir authentifiziert sind. Das heißt, wir nehmen einfach die ZIP-Datei vom Plugin, klicken auf hochladen und dann erscheint das später auch im Repository. Genau,

also wir haben jetzt hier so ein paar Features in unserer Anwendung. Die das heißt, ich kann auch Plugins auf privat stellen, da kann nur ich oder nur Leute in der Gruppe, die auch sehen, die quasi runterladen. Genau, wir können auch bei

den Nutzern einstellen, ob sie Plugins hochladen können oder auch nur quasi Plugins lesen, auf die sie Berechtigung haben. Und was wir jetzt gerade neu in Arbeit haben, wir haben auch quasi LDAP oder Active Directory quasi als Backend unterstützt, dass wir quasi auch dort die Nutzergruppen rausladen können, sodass Unternehmen oder Verwaltungen, die jetzt ein Plugin-Repository

bereitstellen wollen, nicht noch mal extra eine eigene Nutzerverwaltung dort für das Plugin-Repository brauchen. Genau, und wir haben das Ganze so gemacht, dass wir es individuell anpassen können. Das heißt, wenn es dann auch andere Anforderungen gibt. Genau, jetzt gehe ich noch mal ein

bisschen tiefer in die Materie, weil das waren gerade die Basics, was man auch brauchen, Kugis Plugin-Repository bereitzustellen. Aber Kugis kann quasi noch mehr, zumindest beim offiziellen Repository, gibt es nämlich diese Remote Procedure Calls. Da ist es auch möglich, Plugins direkt über

die Kommandozeile über diesen Remote Procedure Call hochzuladen. Oder halt auch, ich weiß nicht, vielleicht kennt ihr aus Kugis aus dem offiziellen Plugin-Repository, wenn ihr danach Plugins guckt, gibt es auch die Möglichkeit, quasi eine Stimme abzugeben, 1 bis 5 Sterne oder so war

das, glaube ich. Genau, hier steht es 1 bis 5. Das ist auch quasi über diesen Remote Procedure Call unterstützt. Der Haken an der Sache ist aktuell jedoch, dass dieser Endpunkt in Kugis in dem offiziellen

Plugin-Repository, dass er halt hart kodiert im Kugis-Quelcode ist. Das heißt, wir können da jetzt nicht unseren Remote Procedure Endpunkt quasi wählen. Das heißt, ich habe das mal ausprobiert und dann habe ich in meinem Repository ein Plugin angeklickt und gevoted. Und das tut mir jetzt auch leid, aber dieser Vote geht dann quasi an das offizielle Kugis

Plugin-Repository, an ein Plugin mit zufällig derselben ID. Also das tut mir leid in dem Fall. Ihr habt auf jeden Fall 5 Sterne gekriegt für euer Plugin. Falls jemand jetzt hier vom Kugis-Projekt sich das Ganze mal anschauen kann, ich habe ein Issue aufgemacht. Ich wäre doch gerne

bereit, da zusammen zu arbeiten und eventuell auch ein Pull Request zu machen, wenn ich da ein bisschen Zeit für finde. Ich glaube, wir haben noch genug Zeit, dass ich jetzt die Demo-Seite noch kurz zeige. Ich habe jetzt für die Foskis quasi eine Instanz gemacht, wo wir das quasi

testen können, wo ihr auch alle quasi jetzt eingeladen seid, nach dieser Veranstaltung eure Kugis Plugins hochzuladen. Genau, und in Kugis dann gerne zu testen und mir auch gerne Feedback zu geben. Also, ja, genau, also, genau, also ihr könnt euch hier, das sind

die Zugangsdaten. Ich werde es jetzt vielleicht einfach mal zeigen. Ich glaube, es war, ja, genau, hat geklappt. Perfekt. Also, bis jetzt, ich kann mal kurz aktualisieren, ob jemand schon

schneller war. Also, bis jetzt ist ja nur das Plugin, was ich gestern vorgestellt habe, zu finden. Unter How to habe ich auch noch mal kurz erklärt, was man so machen kann. Hier steht auch noch mal zum Nachlesen der Nutzernahme und das Passwort. Genau, hier ist auch direkt der Link, wie man es in Kugis quasi

einfügen kann. Ihr seid auch gerne eingeladen, hier eine Authentifizierung zu testen. Also, ihr kennt ja alle das Passwort. Das müsste auch funktionieren. Also, ihr habt jetzt nicht mehr Plugins, dann oder weniger, aber das müsste auch halt funktionieren, jetzt hier in Kugis die Authentifizierung quasi zu nutzen. Und ihr könnt auch, ich

habe hier schon ein paar Plugins verwendet. Dort habe ich bereits ein Pull Request eingereicht, dass man dort quasi nicht nur aufs offizielle Kugis Plugin Repository über den Remote Procedure Code Plugins hochladen kann, sondern auch auf ein beliebiges. Und hier findet ihr auch quasi die

Kommandozeile, wie ihr euer mit Kugis Plugin CI geschriebenes Plugin oder eingerichtetes Plugin direkt quasi aus der Kommandozeile bei uns aufs Repository laden könnt. Genau, kann ich mal kurz zeigen. Hier kann man sich dann einloggen.

Können wir auch mal speichern für später. Genau, dann könnte ich hier auf Upload gehen. Ich habe hier auf dem

Demonstrationsrechner keine Datei, aber wenn wir jetzt hier ein Kugis Plugin hätten, können wir das hier direkt hochladen. Und dann findet man das auch auf der Liste. Kann ja auch sich die Detailansicht angucken. Genau. Gibt es dann auch der Link zum Repository wird auch ausgeladen. Man kann es auch hier von der Webseite direkt

runterladen und dann manuell installieren. Genau. Und wir haben auch das Download. Wir können auch mitschneiden, wie viele Downloads es gibt. Das erscheint dann auch in Kugis. Genau. Das war es glaube ich soweit. Gibt es noch Fragen?

Herzlichen Dank, Friede, an dich für die Vorstellung. Ja, gibt es Fragen? Ja, eine Frage zu dieser Webseite. Wenn da das Plugin

hochgeladen wird, gibt es da irgendwelche Tests, ob das Plugin auch korrekt ist? Also da kommt ja ein ZIP-File an. Also du bist gerne eingeladen, das auszuprobieren. Aber ich habe da schon so ein paar Tests eingebaut. Also ich glaube, ich weiß jetzt nicht gar nicht.

Genau. Auf jeden Fall habe ich in dem Vortrag ist auch das GitHub Repository verlinkt. Das heißt, ihr könnt euch auch gerne die Tests angucken, die da gemacht werden. Genau. Aber es wird schon, es werden schon ein paar Sachen abgefragt, wie zum Beispiel, wir müssen ja die Metadata TXT

Datei in der ZIP-Datei finden. Es wird geguckt, ob es eine ZIP-Datei ist, eine korrekte. Genau. Ich weiß nicht, ob man da sonst noch irgendwie böse Dinge mitmachen kann, aber es wird ja eigentlich nur bereitgestellt. Man kann die ZIP-Datei dann runterladen. Also wir können nicht testen,

ob das Plugin im Endeffekt in Kugels auf funktioniert. Das ist nicht getestet. Also ich dachte da auch eher so an diese Plugin Größe oder ob es da eine Limitierung geben sollte. Nicht, dass da ein Gigabit großes Kugels Plugin hochgeladen wird. Ich glaube, das ist auf Web-Server-Seite

eingestellt. Aber ich weiß jetzt nicht, könnt ihr gerne ausprobieren, wie groß das Kugels Plugin sein kann. Also ich denke immer, dass es eine Limitierung gibt. Und habt ihr hier auch eine Historie drin, wenn ich jetzt so ein Plugin, du hast ja geschildert, dass man dann die neuen Stände immer hochladen kann von einem Plugin. Genau, die Historie haben wir jetzt noch nicht drin. Normal wird quasi immer das

aktuellste Plugin bereitgestellt. Genau, das ließe sich durchaus auch quasi überlegen, ob man quasi dann noch quasi die Version vorher wiederladen kann oder so. Okay, und dann gibt es noch eine Frage. Ist der Code für das Plugin Repository, ist der Open Source, wenn ich jetzt sowas selbst betreiben möchte?

Ja, ich kann es ja auch mal kurz zeigen.

Ich hoffe, das ist jetzt richtig. Ja, genau, also das ist auch, wie gesagt, nochmal verlinkt in dem Vortragsbeschreibung. Genau, also es ist Open Source. Es gibt auch einen Docker

File, also man kann es auch quasi direkt mit Docker bauen direkt und sein eigenes lokales Plugin Repository in zwei Minuten ausprobieren. Ja wunderbar. Dann haben wir noch eine Frage. Gibt es eine Möglichkeit mit GitHub Actions eine ähnliche

Lösung zu erstellen? Bestimmt. Bestimmt, okay. Also ich habe da jetzt noch nicht viel mit GitHub Actions ausprobiert, aber ich denke mal, da kann man ja auch quasi, also ich habe da mal so kurz rein geschaut, das ist auch schon ein paar Jahre her, dass man quasi, wenn man jetzt einen, wenn man jetzt quasi einen Commit macht und

dann irgendwie einen Tag macht, neues Release 1.4 oder so, dass dann quasi dieses Plugin runtergeladen wird und im Repository bereitgestellt wird. Also da habe ich auch schon mal Tests zugemacht, das ist auch grundsätzlich möglich, aber wir hatten, aber es war jetzt nicht in unserem Workflow drin quasi bisher.

Gut, ja dann nochmal hier in den Raum. Gibt es hier noch eine Frage aus dem Publikum? Das sieht jetzt nicht so aus. Herzlichen Dank nochmal an dich, Frieda, für den Vortrag. Danke für eure Aufmerksamkeit.