I am embarrassed about how late I was to learn that WinGet existed. It was only after I came back from years of Ubuntu as a daily driver that I googled "windows package manager" and discovered it.
Don’t be too embarrassed, WinGet is only 5 years old and is nothing more than an alternative to Scoop and Choco.
It’s « just » a tool which will fetch installation manifests on a centralized Microsoft GitHub repository and execute it. Exactly like brew or chocolatey. It’s fine for a third party « package manager » but it feels pretty weak for an official system tool.
Also, if I’m not wrong, it’s only available as a CLI tool which makes it pretty useless for 95 percent of Windows users and for developers to distribute software with it.
The thing is useful for sure but it’s far from a Linux package manager.
> Also, if I’m not wrong, it’s only available as a CLI tool which makes it pretty useless for 95 percent of Windows users and for developers to distribute software with it.
Back in my day this would be seen as an exercise left for the user, and thus a new junior dev was born building a front end.
These comments led me to searching winget gui.
UniGetUI looks really cool.
https://github.com/marticliment/UniGetUI - 16.2k stars
It is cool and I use it regularly. But keep in mind that it’s yet another one person OSS project and can bite the dust *at any time*.
If you have the ability to financially support them or contribute code somehow, do it.
Total tangent, but I just snooped into your bio. Could you please list a few of the design blogs that you mention there?
I've also been quickly impressed this week with the winget UI now provided inside Command Palette, the new PowerToy "Sherlock/Spotlight" search tool.
> It’s « just » a tool which will fetch installation manifests on a centralized Microsoft GitHub repository and execute it.
The winget repo has a ton of useful installation manifests, sure, but isn't "just" a tool to fetch manifests from that one repo. (Also, it doesn't fetch the data directly from GitHub, even though that is the source of truth, it has a light REST service in between which does a lot of caching and DDoS management and what have you.) Winget also by default installs Windows Store apps, too. It's also configurable so you can add your own installation manifest repos if you wish (such as on-premise private feeds).
scoop, Choco, and winget are all very different. winget is closest to Choco in that it prefers to just run regular installers. It keeps its own state of installed packages, though, while winget uses the same sources of truth as "Add/Remove programs" (msstore/appx and the "uninstall" group in the registry). Scoop is its own thing that installs everything under its own prefix and manages its own state.
>winget uses the same sources of truth as "Add/Remove programs" (msstore/appx and the "uninstall" group in the registry).
I find that behavior incredibly annoying. I mainly use Chocolatey, so every once in a while when a package is heavily outdated or missing from the repo I end up using Winget instead for convenience's sake. That means Winget keeps trying to update or manage Chocolatey packages, and as far as I know, there's no easy way to stop that.
The thing about Chocolatey is that, iirc, it’s still largely community members maintaining that registry. Not the best in a cybersecurity context, and some firms may have licensing against unauthorized distribution of their installer files like that.
Hence WinGet, a Microsoft owned and operated alternative that those firms may feel less jittery about.
I really prefer Scoop over WinGet. Scoop installs most packages into exactly one folder and sets up shims/links. And it has an unified install/update methodology.
WinGet is more or less just downloading the installers and running them, and doesn't properly track the installed applications and isn't always able to update them.
> doesn't properly track the installed applications and isn't always able to update them.
How so? I’ve been using it for years and haven’t had a problem yet updating all applications at once.
It depends on the application.
Things can get tricky with applications that are installed with WinGet but come with mechanisms to update themselves. If this self-update skips adjusting the right knobs and values in the registry, WinGet will assume that the application is still on the initial version.
For example, this is the case with Obsidian.
I am embarrassed for Microsoft with how long it took them to implement WinGet. It still leaves much to be desired, but I guess if you’re used to PowerShell, then weird period-delimited CamelCase package names are probably something that fits your current routine experience anyway. Coming from apt/yum/brew, it feels almost hostile to the user that even the most basic packages must be searched for just to confirm the syntax of their name.
MS did not implement Winget. They stole code from another app called appget.