Windows Package Manager 1.4
The Windows Package Manager team has been busy working on WinGet 1.4. This release introduces support for .zip-based packages. WinGet can now extract and run an installer inside of a .zip archive or install one or more portable packages from an archive. The WinGet open-source community has also been busy adding new features like command aliases to help with muscle memory if you use more than one package manager, and a wait argument to keep winget.exe open long enough to see what’s happening if it’s called from other applications.
WinGet Show Improvements
A few more manifest values like tags and purchase URL were added to the output (if they are present) of
winget show <package>. Below I have an example running
winget show oh-my-posh -s winget. Since Oh My Posh is available both in the Microsoft Store and the Windows Package Manager community repository, I narrowed the results down to the “winget” source. If you like the colorful display in my prompt, that’s the prompt theme engine I’m using.
Muscle memory can be hard to overcome. If you’ve ever tried to type “dir” on a Linux system or “ls” on Windows, you know what I mean. Several new command aliases have been added to WinGet that might help a little. When you run
winget with no arguments, the default help displays the available commands. If you drill in a bit running
winget <command> --help you will see if any aliases are available. Below, you can see “find” is an alias for “search”. Other command aliases include
add for install,
update for upgrade,
rm for uninstall,
ls for list, and
config for settings.
As you might expect, you can now run
winget find vscode and the same output is displayed as if you had run
winget search vscode.
Note: The results displayed when searching the Windows Package Manager Community repository are ordered by a “best match” heuristic. WinGet evaluates the name, identifier, moniker, and tags. They are also more inclusive than “show” where WinGet is trying to find a single best match to use for install.
Install / Upgrade Flow Enhancements
Some packages require an explicit argument to be passed in order to perform an upgrade. This was causing winget to fail if a user ran
winget install <package> and the package was already installed on the machine. We made some additional enhancements to detect that the package was already installed and switch to the upgrade flow. If you don’t want the upgrade, you can pass
--no-upgrade. This is most commonly encountered in scritped scenarios. We’ve also noticed several packages can upgrade themselves, so our default behavior is to allow them to do so. If you run
winget upgrade --all and one or more of these packages are encountered, they will be skipped. If you want to include them, just add
WinGet now supports installing packages contained within a .zip archive. This feature builds on the existing support for portable packages, and existing installer support for MSIX, MSI, and EXE-based installers. Our initial support includes either a single installer, or (one or more) portable package(s). We’ve kept the Issues and PRs (Pull Requests) open at GitHub and added the “.zip” label to them. Once this release rolls out to the majority of supported Windows systems, we will begin validating the existing PRs and accepting new ones.
Wait, there’s more. (I couldn’t help myself) Sometimes when you’re scripting things, or debugging, you want a prompt. It can be quite frustrating to see a terminal window display some text and then disappear before you can read everything. Just add