Native package management of Microsoft Windows package Management with WinGet CLI
It has taken decades, but finally there is a Windows-own package management-well, soon at least. It is still a preview, but packaging can already be carried out now – bumpy road included.
Companies on the topic
WinGet will provide an easy way to string and distribute software packages for Windows in the future.
(© Kzenon – stock.adobe.com)
One of the biggest advantages of Linux has always been package management: lean command-line clients can easily install dozens of programs at once, including dependencies and ways to uninstall them cleanly later.
The recently presented Chocolatey was the most mature version of a package management for Windows as of 2020. Now Microsoft has clearly recognized the need or at least the benefit has brought its own package management to the start.
The Windows Package Manager is also based on open source software, runs on the command line and of course allows third parties to manage their own packages. The packages are maintained on GitHub, as well as the associated winget client.
Apart from that, however, the two tools are very different in terms of workflow and possibilities.
The Windows Package Manager
Before you can deal with the Windows Package Manager, it wants to be installed first. This currently only works via detours. The simpler version without logging in via Microsoft account: On the GitHub page in the Releases section you will find the compiled WinGet Binary-with a not insignificant disadvantage-so installed there are no updates.
For the more comfortable version, winget-cli is set up together with the app installer. In turn, interested parties receive this via Windows 10 Insider Build or the Package Manager Insiders Program – and then via the correspondingly updated Windows Store.
Once this hurdle has been skipped, you can search for the 7-Zip package in the terminal, for example:
winget search 7zip
… spits out results. In general, the client is quite clear here and comes out with just eight commands, which, however, are constantly expanded:
install: to Install
show: for package details
source: Management of sources
search: Find app and view info
hash and validate: Verification of installation files
settings: for internal settings
key features: to display experimental features (such as support for the Microsoft Store).
Basically, the client works completely smoothly from the user’s point of view – searching, installing and uninstalling runs smoothly. But only at first glance, a second one immediately reveals the early stage in which winget is: no dependencies are taken into account! And that basically makes the whole system completely unusable at the moment.
Of course, there are Tickets to GitHub, and you can probably assume that the function will follow, since the actual joke of a package Manager would otherwise be completely lost. And another much discussed and desired feature is still missing: so far only real installers can be packaged, no ZIP files and no portable programs that consist of only a single EXE. Even if there is a workaround for it.
Another” trifle ” should not go unmentioned: only the manifestos in YAML format are kept, not the actual software. With Chocolatey you can easily “host”your own smaller programs at the same time as the package. For winget you have to provide the installer (s) independently for download.
This is a matter of course for any larger project, but for hobby developers with individual small tools that are no longer being developed on a large scale, it should be an additional hurdle. Whether this will ultimately keep the offer reasonably clean or rather constrict the variety, time must show.
On the positive side, however, the creation of packages should be mentioned. Here, the Microsoft variant is more beginner-friendly than, say, Chocolatey. On the one hand, the package is basically limited to a single YAML file with very simple syntax and very few necessarily required entries. On the other hand, there are tools that make the work as easy as possible.
The WinGetYamlGenerator helps to avoid errors.
(Image: Lang / Peter Torr (Microsoft))
The WinGetYamlGenerator, for example, offers a very simple form to fill in the minimal information. This includes creating a hash of the download files for later review.
The prerequisite is that a tool is already available online-and as mentioned in executable version, ie MSI, EXE or the like. In addition, there should be a link to the selected license, even if only the specification of a license name is mandatory.
It is then possible to use the WinGetYamlGenerator – which, however, almost only implements the mandatory information: after specifying the names of the tool and the publisher, the tool automatically generates a correct ID from it, simply according to the pattern “publisher.nam ” minus certain special characters.
This is followed by the download URL, the version number (which also gives the name of the YAML file), license information and installer variant. Finally, the actual Installer is added. Here the download URL is specified, the installer is downloaded and then used for the calculation of the SHA256 hash.
This is probably where the only possible error lurks: for the selected installer type, its option for an unattended (silent) installation must be specified; for Nullsoft-Installer, for example, “/S”. In the YAML file itself, any switches can be passed, but the silent switch is mandatory. This is still a limitation at present – silent-Install must be supported.
This means that the package is already ready and can be used with the exemplary command “winget validate 1.0.0.yaml“ check. Here is an exemplary manifest of the generator with at least the required information:
Publisher: Meine Projekte
Name: Mein Tool
License: GNU General Public License v2.0
- Arch: x86
You can see: the code is quite trivial, a graphical application is hardly needed a second time.
Publishing in the repository may be a bit more comfortable with Chocolatey because it works directly with the CLI client. However, since the Windows Package Manager repo is hosted on GitHub, the process fortunately follows the standard GitHub workflow via pull requests:
- Windows Package Manager repos on GitHub forks
- Local cloning: git clone mein-fork
- Create branch: git checkout-b my-branch (optional)
- Add Manifest: git add manifestmy-projectsmy-package 1.0.0.yaml
- Commit: git commit-m ” My commit message”
The pull request for the commit can then be created in the Windows Package Manager repo. If you want to add multiple manifests, you need separate branches. This is followed by an automated validation process, in the course of which bot notifications regarding errors and problems can be expected. And you should keep this in mind: there are only seven days left to resolve such issues-otherwise the pull request will be closed automatically.
The Windows package manager could make Windows a lot more workable in the future-if Microsoft goes the right way. The base already fits, but essential functions are still missing. And from the point of view of the open source enthusiasts, there is probably still a little to do around it-not everything is as you are used to and as it corresponds to the sense of free software.
This starts with the almost mandatory login with a Microsoft account, without which there are no updates so far. And statements such as the following are not necessarily to the liking of many FLOSS friends: “Microsoft reserves the right to refuse a transmission for any reason whatsoever.“
Of course, if Microsoft manages the repository with user scripts, you should also decide which packages are included or rejected. But “for whatever reason”? Chocolatey goes into detail about when something is rejected why – transparency is part of open source!
The potential is huge either way, for end users as well as developers and administrators. However, the objection is allowed that the resources from the point of view of Windows itself, the users, developers and admins would certainly be better invested in Chocolatey. Microsoft will see this quite differently, of course.