Die Föderalisierung der Package-Repos

Unter wechselnden Bezeichnungen (mal "Plugins", mal "Package" genannt) befand sich das (offizielle) Package Repository innerhalb eines Sub-Projektes innerhalb des NumeRe-Projektes und wurde auf SourceForge gehosted. Die allgemeine Verfügbarkeit war akzeptabel, so dass Packages fast immer heruntergeladen und installiert werden konnten. Eine Versionskontrolle gab es auch, wenngleich SVN vergleichsweise langsam arbeitet.

Was hingegen nicht so gut bis gar nicht funktioniert hatte, das war die Kollaboration. Es gab zwei mögliche Vorgehensweisen:

• Das hochzuladende Package per Mail schicken und darauf hoffen, dass es von uns hochgeladen wird

• Sich einen SourceForge-Account zu beschaffen, sich für das Repository von uns freischalten lassen und sich danach mit SVN rumärgern müssen

Wie eigentlch zu erwarten war, gab es niemanden, der nennenswert beigesteuert hat. Und das ist verflucht schade, denn wir glauben sehr wohl, dass es da draußen Code gibt, der sich eigentlich exzellent zum Teilen über ein sinnvolles Repository eignet.

Auch wenn es einige Kontroversen über GitHub gibt, so ist diese Plattform doch immer noch exzellent zur Kollaboration geeignet. Insbesondere, da GitHub bis heute noch eine sehr "generöse" REST API bereitstellt, über die wir die Interaktion mit dem Package-Manager durchführen können ohne gleich auf Git angewiesen zu sein. Jedenfalls haben wir uns entschieden, das "offizielle" Package-Repository jetzt auf GitHub zu hosten und damit eine deutlich bessere Möglichkeit zur Kollaboration geschaffen.

Bei der Struktur des Repositories haben wir auch Hand angelegt und uns vom WinGet-Repository inspirieren lassen. Demzufolge sind die Packages in ihre jeweiligen Ordner sortiert, die wiederum Ordner für die Versionsnummern beinhalten. In diesen befinden sich wiederum die eigentliche Package-Datei sowie ein meta.json Manifest. Das Manifest fasst alle Meta-Informationen zu den Packages zusammen und ist eine deutlich kleinere Datei als das eigentliche Package. Damit können wir aber sicherstellen, dass wir Bandbreite sparen und die Zugriffszeit auf das Repository gering halten können.

Natürlich könnte man denken, dass es unsinnig ist, Versionsnummer-Ordner anzulegen, wenn man doch Git verwendet. Tatsächlich wird aber nirgends wirklich Git gefordert und das hat einen guten Grund. Und der liegt in der Tatsache, dass es mehr als ein Package-Repository geben kann. Wir streben nämlich eine Demokratisierung bzw. Föderalisierung verschiedener Package-Repositories an. Manche werden auch privat oder inhouse sein (was vollkommen legitim ist), andere werden einen thematischen Fokus haben und dann wird es wieder Repositories geben, die alternative oder bessere Implementierungen des "offiziellen" Repos enthalten. Jeder Nutzer wird sich selbst entscheiden können, welche Repositories er verwenden will. Dazu muss bloß die jweilige Repository-Konfiguration (das sollten die jeweiligen Repos bereitstellen) in den "/remotes" Ordner kopiert werden.

Auch wenn wir nicht Git für ein Package-Repo erfordern, so erfordern wir doch, dass es eine REST API wie GitHub oder Gitlab bereitstellt. Zum Zeitpunkt, an dem wir das hier schreiben, macht Codeberg das leider noch nicht. Bitbucket könnte funktionieren, es kann aber zu Problemen kommen.