WinGet is not the way forward

What started off as a pretty normal day for most users turned out to be chaotic for users of WinGet, a Microsoft-managed "package" manager that has seen mass adoption due to its Microsoft-backing, dwindling the use of other CLI package installers like Scoop & Chocolatey. The single Azure-based source that WinGet uses for its repo format is experiencing random issues, thus causing CLI to fail with an unhelpful `Forbidden (403)` error. While some packages likely can be updated individually, you won't be able to check which packages are outdated. I guess WinGet developers never thought that their single repo would have issues.

Most Windows package managers, but specifically WinGet, aren't real "package" managers like those available on Linux because they don't actually compile or package anything. Rather, they are comprised of text-based file formats (JSON, YAML, etc.) or scripts (Powershell) that tell the CLI where it can download the packages from the software creator, the expected checksum, switches to pass to the installer to make it silent or for specific features, an "alias" or command provide for portable installers, and some other metadata. Therefore when you install a package using the WinGet CLI, you're downloading the software from the developer directly, and asserting you have the rights to do so & are agreeing to the software terms.

This is similar to how third-party sources on Linux work, like the AUR from Arch Linux, but even less so. With the AUR you're still downloading the software yourself according to a package manifest---although the manifest may also be instructions on compiling it---but ultimately you end up creating a package "bundle" that is actually getting installed.

The AUR tools automate this so the packages are usually cached in a local package repo (from disk), but you can still host a repo with these package bundles prebuilt that you can reuse or that others can use, while being mindful of copyright or license agreements.

Microsoft never documented their original WinGet repository format, and their only official documented solution `winget-cli-restsource` details needing an Azure Cosmos DB database for hosting your own. Microsoft's WinGet doesn't even support a local file-based package repo, rather you have to use the `--manifest` flag for each individual install, and you have to do that every time. If can't detect changes to the manifest, and this is especially cumbersome if you have several software manifests you've created or updated locally because the upstream version is significantly outdated.

Furthermore, later Microsoft introduced something called package scopes. This is similar to Flatpak user installs, without any of the security benefits. The goal here was to use a different installer URL or instructions when a user wanted to install a package that didn't rely on Administrator permissions. Usually the package will get installed to `%LOCALAPPDATA%\Programs`, but is never reliable. I've ran into far too many issues installing software from WinGet while running under an elevated terminal (including explorer.exe crashes), but there may be instances where it is still necessary.

Last, there is the issue of portable packages involving "aliases" & symlinks. Microsoft recommends installing `user` packages over those requiring elevation. But since Windows needs to know where to find CLI tools that you install using WinGet it either uses symlinks or modifies your PATH variable.

However, after installing 20 or more CLI tools your PATH variable will become so long it literally starts to break things in Windows. Windows will throw an error even when you try to modify your PATH variable through the GUI. I ran into this issue with VS Code where I couldn't figure out why certain CLI executables weren't being registered. Turns out, VS Code has issues when your PATH variable is too long.