Natives Paket-Management von Microsoft Windows-Paketverwaltung mit WinGet CLI

Es hat Jahrzehnte gedauert, doch endlich gibt es ein Windows-eigenes Paketmanagement – nunja, bald zumindest. Noch handelt es sich um eine Vorschau, aber das Paketieren lässt sich bereits jetzt durchexerzieren – holprige Straße inklusive.

Einer der größten Vorteile von Linux ist seit jeher das Paketmanagement: Über schlanke Kommandozeilen-Clients lassen sich problemlos Dutzende Programme auf einmal installieren, inklusive Abhängigkeiten und Möglichkeiten, später sauber zu deinstallieren.

Das kürzlich hier vorgestellte Chocolatey war Stand 2020 die am weitesten gereifte Variante eines Paketmanagements für Windows. Nun hat Microsoft die Notwendigkeit oder zumindest den Nutzen offenbar auch erkannt hat eine eigene Paketverwaltung an den Start gebracht.

Der Windows Package Manager basiert dabei ebenfalls auf Open Source Software, läuft auch auf der Kommandozeile und erlaubt es selbstverständlich, dass Dritte eigene Pakete verwalten. Gepflegt werden die Pakete auf GitHub, ebenso der zugehörige winget Client.

Davon abgesehen sind die beiden Werkzeuge aber doch sehr unterschiedlich, was Workflow und Möglichkeiten angeht.

Der Windows Package Manager

Bevor man sich mit dem Windows-Paket-Manager beschäftigen kann, will dieser zunächst installiert werden. Dies funktioniert aktuell nur über Umwege. Die einfachere Variante ohne Anmeldung per Microsoft-Konto: Auf der GitHub-Seite im Bereich Releases findet sich die kompilierte WinGet Binary – mit einem nicht unerheblichen Nachteil – so installiert gibt es keine Updates.

Für die im Nachgang komfortablere Variante wird winget-cli zusammen mit dem App Installer eingerichtet. Diesen wiederum bekommen Interessierte per Windows 10 Insider Build oder das Package Manager Insiders Program – und dann jeweils über den entsprechend aktualisierten Windows Store.

Sobald diese Hürde einmal übersprungen ist, können Sie im Terminal beispielsweise nach dem Packprogramm 7-Zip suchen:

winget search 7zip

… spuckt entsprechende Ergebnisse aus. Generell ist der Client hier recht übersichtlich und kommt mit gerade mal acht Kommandos aus, die allerdings stetig erweitert werden:

install: zum Installieren

show: für Paketdetails

source: Verwaltung der Quellen

search: App finden und Info anzeigen

hash und validate: Verifizierung von Installationsdateien

settings: für die internen Einstellungen

features: zum Anzeigen experimenteller Funktionen (etwa Support für den Microsoft Store).

Grundsätzlich funktioniert der Client aus Nutzersicht völlig problemlos – das Suchen, Installieren und Deinstallieren läuft glatt durch. Aber nur auf den ersten Blick, ein zweiter offenbart gleich, in welch frühem Stadium winget ist: Es werden keine Abhängigkeiten berücksichtigt! Und das macht das ganze System derzeit im Grunde völlig unbrauchbar.

Natürlich gibt es entsprechende Tickets auf GitHub und man darf wohl davon ausgehen, dass die Funktion folgen wird, da der eigentliche Witz eines Paketmanagers ansonsten völlig verloren ginge. Und noch ein viel diskutiertes und erwünschtes Feature fehlt noch: Bislang können ausschließlich echte Installer paketiert werden, keine ZIP-Dateien und keine portablen Programme, die nur aus einer einzelnen EXE bestehen. Auch wenn es dafür immerhin einen Workaround gibt.

Eine weitere „Kleinigkeit“ sollte nicht unerwähnt bleiben: Es werden nur die Manifeste im YAML-Format vorgehalten, nicht die eigentliche Software. Bei Chocolatey lassen sich problemlos eigene kleinere Programme gleichzeitig mit dem Paket „hosten“. Für winget muss man den oder die Installer eigenständig zum Download bereitstellen.

Für jedes größere Projekt ist das eine Selbstverständlichkeit, aber für Hobbyentwickler mit einzelnen kleinen Tools, die nicht mehr groß weiterentwickelt werden, dürfte es schon eine zusätzliche Hürde darstellen. Ob das letztlich das Angebot halbwegs sauber halten oder eher die Vielfalt einschnüren wird, muss die Zeit zeigen.

Auf der positiven Seite ist aber das Erstellen von Paketen zu erwähnen. Hier ist die Microsoft-Variante einsteigerfreundlicher als etwa Chocolatey. Zum einen beschränkt sich das Paket im Grunde auf eine einzelne YAML-Datei mit sehr simpler Syntax und sehr wenigen zwangsläufig benötigten Einträgen. Zum anderen gibt Tools, die die Arbeit so einfach wie nur möglich machen.

Der WinGetYamlGenerator beispielsweise bietet ein ganz simples Formular zum Ausfüllen der Minimalinformationen. Dazu gehört auch das Erstellen eines Hashs der Download-Dateien für die spätere Überprüfung.

Paketieren

Voraussetzung ist, dass ein Tool bereits online verfügbar ist – und wie erwähnt in ausführbarer Version, sprich MSI, EXE oder dergleichen. Zudem sollte ein Link zu der gewählten Lizenz bestehen, auch wenn nur die Angabe einer Lizenz-Bezeichnung obligatorisch ist.

Anschließend ist es möglich, den WinGetYamlGenerator zu verwenden – der allerdings fast nur die Zwangsangaben umsetzt: Nach Angabe der Namen des Tools und des Publishers erzeugt das Tool automatisch eine korrekte ID daraus, schlicht nach dem Muster „publisher.nam“ abzüglich bestimmter Sonderzeichen.

Es folgen Download-URL, die Versionsnummer (aus der sich auch der Name der YAML-Datei ergibt), Lizenzangaben und Installer-Variante. Zum Schluss wird der eigentliche Installer hinzugefügt. Hier wird die Download-URL angegeben, der Installer heruntergeladen und dann für die Berechnung des SHA256-Hashes herangezogen.

An dieser Stelle lauert wohl die einzige Fehlermöglichkeit: Für den gewählten Installer-Typ muss dessen Option für eine unbeaufsichtigte (Silent-) Installation angegeben werden; für Nullsoft-Installer zum Beispiel “/S”. In der YAML-Datei selbst können beliebige Schalter übergeben werden, aber der Silent-Schalter ist obligatorisch. Das ist nämlich noch eine Einschränkung derzeit – Silent-Install muss unterstützt werden.

Damit ist das Paket auch schon fertig und lässt sich mit dem beispielhaften Befehl „winget validate 1.0.0.yaml“ überprüfen. Hier ein beispielhaftes Manifest des Generators mit den mindestens erforderlichen Angaben:

Man sieht schon: Der Code ist ziemlich trivial, eine grafische Anwendung wird dafür kaum ein zweites Mal benötigt.

Veröffentlichen

Das Veröffentlichen im Repository mag bei Chocolatey etwas komfortabler gelöst sein, weil es direkt mit dem CLI-Client funktioniert. Da das Windows-Paket-Manager-Repo aber auf GitHub gehostet wird, folgt der Ablauf erfreulicherweise dem Standard-GitHub-Workflow über Pull Requests:

• Windows-Package-Manager-Repos auf GitHub forken

• Lokal Klonen: git clone mein-fork

• Branch erstellen: git checkout -b mein-branch (optional)

• Manifest hinzufügen: git add manifests\meine-projekte\mein-paket\1.0.0.yaml

• Committen: git commit -m “Meine Commit-Nachricht”

• Hochladen: git push

Anschließend lässt sich der Pull Request für den Commit im Windows-Package-Manager-Repo anlegen. Wer mehrere Manifeste hinzufügen möchte, benötigt separate Branches. Anschließend folgt ein automatisierter Validierungsprozess, in dessen Verlauf unter Umständen Bot-Benachrichtigungen bezüglich Fehlern und Problemen zu erwarten sind. Und die sollte man dringend im Auge behalten: Es bleiben nur sieben Tage Zeit, solche Issues zu lösen – andernfalls wird der Pull Request automatisch geschlossen.

Fazit

Der Windows-Paket-Manager könnte Windows in Zukunft um einiges praktikabler machen – wenn Microsoft den richtigen Weg geht. Die Basis passt schon jetzt, aber es fehlen noch essenzielle Funktionen. Und aus Sicht der Open-Source-Enthusiasten dürfte sich wohl auch drumherum noch ein wenig tun – nicht alles ist so, wie man es gewohnt ist und wie es dem Sinn freier Software entspricht.

Das beginnt mit der fast obligatorischen Anmeldung mit einem Microsoft-Konto, ohne die es bislang keine Updates gibt. Und auch Aussagen wie folgende stoßen bei vielen FLOSS-Freunden nicht unbedingt auf Gegenliebe: „Microsoft behält sich das Recht vor, eine Übermittlung gleich aus welchem Grund abzulehnen.“

Freilich, wenn Microsoft das Repository mit Nutzerskripten verwaltet, sollen sie auch entscheiden, welche Pakete aufgenommen oder abgelehnt werden. Aber „gleich aus welchem Grund“? Chocolatey geht ausführlich darauf ein, wann etwas warum abgelehnt wird – Transparenz gehört nun mal zu Open Source!

Das Potenzial ist so oder so gigantisch, sowohl für Endverbraucher als auch für Entwickler und Administratoren. Allerdings sei der Einwurf erlaubt, dass die Ressourcen aus Sicht von Windows selbst, der Nutzer, Entwickler und Admins sicherlich besser in Chocolatey investiert wären. Microsoft wird das ebenso selbstverständlich ganz anders sehen.

(ID:47021084)