Windows Package Managers
Updated 44 Days AgoPublic
Actions

Windows remains in the dark ages and doesn't tend to handle installation via package managers, rather it's a libertarian paradise where every application gets to choose how it gets installed and has to provide the infrastructure to do so. The best one can do is create .msi files which are "Windows Installer" packages which is technically then handled by a package manager, but (a) those packages are pretty basic and (b) that's then merely packages, no repositories.

To get some of the user friendliness of stuff like #Linux into #Windows, you have to use something else.

List of Windows package managers

Name	Interface	Source and destination	Available
Microsoft Store	GUI	Installs apps per-user from a single central Microsoft-run repository of .msix and .appx packages	NT 6.2+
WinGet aka "Windows Package Manager"	CLI	Installs apps from a Microsoft-run repository of .exe and .msi(x) installers or the Microsoft Store (or a custom repo but that seems like a pain in the ass)	NT 10.0+
Chocolatey	CLI	Installs system-wide from an open repository or custom repositories of NuGet packages	NT 6.1+
PackageManagement	CLI	PowerShell module for NuGet packages that points at the Chocolatey repo by default	PS 5.1+
Scoop	CLI	Installs per-user and without shared libraries from packages defined by simple JSON manifest, default repository focused on Free Software and Scoop aims to essentially be a modern (and more `apt`-like) Cygwin	NT 6.1+ via PS 5.1+

External comparisons and lists:

Frontends

For winget, [[ https://github.com/marticliment/WingetUI | WingetUI (soon to be UniGetUI)] is the open-source leading light. @keithzg has yet to use it tho.

Known Issues

Because nothing on Windows is ever easy . . .

WinGet over SSH

You may be like, oh well if there's an official package manager why would I ever use anything else other than for packages that aren't in it? Well the problem is that over some remote sessions like SSH, shit's entirely broken. See winget-cli issue 1474 for an example which seems to imply SSH just won't work, though @keithzg has run into issues along a different line:

Do you agree to all the source agreements terms?
[Y] Yes  [N] No: Y
Failed when searching source: winget
An unexpected error occurred while executing the command: 
0x8a15000f : Data required by the source is missing

# edit 2023-06-14: Same repro, different error message, same solution as below
Failed in attempting to update the source: winget
Failed when searching source; results will not be included: winget

Solved with the following, cribbed from a comment on an open issue about not being able to bootstrap WinGet automatically:

Elevated PowerShell session


Invoke-WebRequest 'https://cdn.winget.microsoft.com/cache/source.msix' -OutFile '.\Microsoft.Winget.Source.msix' -UseBasicParsing
Add-AppxPackage -Path 'Microsoft.Winget.Source.msix';

I commented on this on a new issue where someone was wondering if WinGet is down so hopefully someone will chime in if this is a bad idea.

Newly installed stuff isn't in PATH

It's very Windows behavior—even opening a new PowerShell session from the CLI won't work. But this (from https://github.com/microsoft/winget-cli/issues/549#issuecomment-1539093267) will:

$Env:Path = [System.Environment]::GetEnvironmentVariable("Path","Machine") + ";" + [System.Environment]::GetEnvironmentVariable("Path","User")

Microsoft Store somehow isn't installed

Look, it can happen, and only one of the times was it even anything I did intentionally! Only fix I found that worked was

# got this from a Microsoft forum
Get-AppXPackage *WindowsStore* -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}  

# haven't tried this but I think it'd work with less wiggle room for future error?
Get-AppXPackage Microsoft.WindowsStore | Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"