Page MenuHomePhorge

Windows Package Managers
Updated 8 Days AgoPublic

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

NameInterfaceSource and destinationAvailable
Microsoft StoreGUIInstalls apps per-user from a single central Microsoft-run repository of .msix and .appx packagesNT 6.2+
WinGet aka "Windows Package Manager"CLIInstalls 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+
ChocolateyCLIInstalls system-wide from an open repository or custom repositories of NuGet packagesNT 6.1+
PackageManagementCLIPowerShell module for NuGet packages that points at the Chocolatey repo by defaultPS 5.1+
ScoopCLIInstalls 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) CygwinNT 6.1+ via PS 5.1+

External comparisons and lists:


For winget, [[ | 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 '' -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 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"
Last Author
Last Edited
Wed, Jun 12, 8:32 PM