The workflow to submit new packages seems easy enough, it's a simple PR process to a GitHub repo [0], if you want to try to help fix that.
The big thing is that winget requires "proper" MSI or MSIX-backed installers (MSIX, MSI, APPX, and most .exe installers) rather than scripts so given the list you've provided some of what you may need is to better help some of the upstream packages clean up their installers/fix bugs in their installers on Windows. (Package update weirdness sounds like a common class of installer bug, sadly.)
That installer focus is one of the things I like and trust about winget. For the most part it is really easy to verify that winget isn't automating much more than what you could do by hand: it is often grabbing the exact same installer you'd go to someone's website to grab, validating hashes for that installer, then running it (in silent mode). One of the reasons I gave up on Chocalatey years ago was too many "packages" were complex PowerShell scripts and I started feeling like I needed to audit every single one (and every version of it) before running it. Some of the "common" packages were full of opinionated scripts that were doing way too much, and some of the uncommon scripts would sometimes have malware in their scripts (and that may be a late change after years of good scripts, too); I reported it every time I saw it, but at some point you report too many and you lose trust in the whole ecosystem. At the moment trusting winget is still quite a bit easier, even after the burnout I had from choco.
That's also what is bad about winget - not having scripting language. AFAIK there were 0 incidents with choco scripts, they are mostly trivial to review (choco also has team of reviewers and no package can be published without being reviewed) and many tools simply can't be installed without PowerShell - the idea of "help some of the upstream packages clean up their installers" is irrational and unrealistic - some of those tools may be even done with the upgrades, which doesn't mean they shouldn't get a package.
Furthermore, many choco packages are embedded and contain the software, which means they can be cached (artifactory, nexus etc.) do not depend on vendor location and can work forever (like development dependencies). All of this makes winget vastly inferior to choco at this moment and suitable for hobby/home use, not serious things like maintaining CI/CD pipeline.
Choco package number and speed of update is on par with Arch.
The good thing about winget is it comes with Windows, which is probably the only one at this point.
I appreciate that we're probably going to continue to have opposite opinions on this.
MSI (and MSIX) are complex databases of pain, but they absolutely know how to uninstall everything that they are told to install and that machinery is well tested now across way too many Windows versions. On the other hand, if someone even bothers to test a script-based uninstall is a crapshoot.
> the idea of "help some of the upstream packages clean up their installers" is irrational and unrealistic
Not really, it is standard open source practice. Installers aren't the most interesting or glamorous thing to maintain so they often welcome any help that they can get.
Most Windows users still don't use any package manager in 2023 and still prefer good installers directly from upstream sources.
> some of those tools may be even done with the upgrades, which doesn't mean they shouldn't get a package.
Ruby's Windows installer has long been run by third party developers. Git for Windows started as a third party operation before getting officially blessed. Open source is full of instances where the person packaging the software is not the original developer. (That most of Linux packaging, even, it's not just a Windows phenomenon.) Without "official" blessing from upstream it can be hard to get people to trust your distribution, but if upstream isn't bothering with maintenance anyway, it is no longer their project. (That's also extremely common in Linux software packaging, new maintainers are often blessed because they did a good packaging job.)
> Furthermore, many choco packages are embedded and contain the software
My experience was very few of the packages I used did that and almost all revolved around some ad hoc Invoke-WebRequest or similar somewhere in their PowerShell scripts, but obviously that is my own anecdotal experience and I'm glad for you that you've had a better time trying to CI/CD with choco than I ever had.
Some people have built custom sources for winget to help with CI/CD scenarios. Out-of-the-box caching/CDN for the primary public sources is still an active discussion, but the neat thing is that it is an active discussion out on GitHub so that you can directly voice your "serious" use cases, if you wish. A good thing about winget is that it is extensible (custom sources) and developed in the open on GitHub (Chocolatey went corporate and a lot of discussion moved proprietary and some of it went closed source years ago).
> Open source is full of instances where the person packaging the software is not the original developer.
How is that different. You seem to compare about method/language used.
> MSI (and MSIX) are complex databases of pain, but they absolutely know how to uninstall everything that they are told to install and that machinery is well tested now across way too many Windows versions.
They can do whatever developer wanted to do. Otherwise, we wouldn't have those gazilions of special cleaners/uninstallers we have
> My experience was very few of the packages I used did that and almost all revolved around some ad hoc Invoke-WebRequest
> Some people have built custom sources for winget to help with CI/CD scenarios
Yeah, you can fix anything. I keep rejected choco packages on my github too.
> Out-of-the-box caching/CDN for the primary public sources is still an active discussion,
I wouldn't use CDN, its just one dependency replaced by another. Cashing is irrelevant if you do not embed the software.
> but the neat thing is that it is an active discussion out on GitHub so that you can directly voice your "serious" use cases
You can have active discussion on GitHub with choco guys. I am sure results in winget case are not going to be much different. In my experience, way more pain than being useful.
So, to recap, the setup is almost the same with choco being small company and MS not. Choco is vastly better with features. I am moving to winget for various other reasons, that I won't talk about here and it has nothing to do with the tech.
>> MSI (and MSIX) are complex databases of pain, but they absolutely know how to uninstall everything that they are told to install and that machinery is well tested now across way too many Windows versions.
> They can do whatever developer wanted to do. Otherwise, we wouldn't have those gazilions of special cleaners/uninstallers we have
The MSI engine was built out of the pain of Windows 3.11 DLL Hell and is not the hero that Windows deserved but the unfortunate anti-hero that Windows needed.
Have you ever tried to build an MSI directly? (With WiX, for example?) These are complex databases of pain precisely because they track file history and dependency maps to an absurd degree because MSI expects a need to rollback everything at any time, but also can't break other apps and needs to be able to repair things.
MSI's biggest problems aren't that it does whatever developers want to do, but that it wants to do a lot of things developers don't want to do or care about. That's why few developers actually want to build installers with something like bare metal WiX and still use MSI builders like NSIS and InstallShield and Active Installer and a million others. Those builders certainly give developers an impression that they do whatever the developers want them to do, but MSI is a leaky abstraction at best and they still have warts from it on the one side (there are so many of these builders because they eventually all get eaten up inside from the complexity and harshness of MSI), and on the other side some of their "do whatever you want" they offer to developers are custom shims (InstallShield notoriously included some incredibly buggy ones that Windows to this day monkey patches bug fixes into) or custom scripting languages (NSIS can do pure MSI, but also makes it way too easy to just write custom scripts that skip the MSI engine altogether).
We have gazillions of "cleaners/uninstallers" not due to deficiencies in MSI itself, but due to:
* Weird non-MSI shims embedded into EXEs
* Weird scripts that run outside of MSI
* Users confusing Program Files/Program Data and User Data and assuming that uninstallers should remove User Data they generated
* "Make my computer appear to be faster" will always be a massive vector for spyware and adware (most of the "cleaners/installers" out there are one, the other, or both; arguably most of them are also actively dangerous to system performance because the Windows Registry is ultimately a big dumb MRU cache and regularly churning that cache in search of "cleaning" deoptimizes the actual things that need to be cached for fast access and also the Registry is optimized for infrequent writes/deletes and the "cleaners" are bad about thrashing that performance too)
(MSIX is a lot easier to write by hand than MSI with WiX, but also makes even more assumptions about file versioning and package management locations and is even less "do whatever the developer wants" by default and needs to opt-in to increasing levels of developer "I solemnly swear I know what I'm doing." that eventually get developers back to WiX levels of complexity with a subtly different XML syntax.)
> It was the case in the history, 5+ years back.
I'm glad to hear choco has gotten better than when I quit using out of script auditing pain.
> I wouldn't use CDN, its just one dependency replaced by another. Cashing is irrelevant if you do not embed the software.
Caching/CDN here means "embedding": it is a map from Official Installer URL to some Hosted Installer URL with high replication (CDN) and locality (CDN+Local Caching). With Choco embedding you are paying Choco to host installers on their CDN and then happy with your local caching options as you download them. The only big remaining difference for "embedding" is that Choco uses ZIP files that contain both XML metadata for choco and installers (.PS1, .BAT, .EXE, .MSI, .MSIX, etc) whereas winget's current architecture would have you cache two files (YAML manifest and .MSI/.MSIX/.EXE installer). If you like, you could also ZIP the two together for true "embedded", but there are some benefits to not doing that as well.
> You can have active discussion on GitHub with choco guys. I am sure results in winget case are not going to be much different.
I did have some bad experiences trying to discuss something with choco over GitHub. It didn't feel like they were using GitHub Issues as primary and instead were using some other issue tracker, I don't know what. It's again possible that these bad experiences were early in the license switch from being a purely open source project to being closed source with open source "customers" and things may have gotten better since those experiences that I had. The current website doesn't give a great impression on this: the only GitHub link in the header and footer is just a "social media icon". The Report Bugs page does link directly to two GitHub repos, but at the bottom as implied last resorts (unless "Security") and instead suggests you use Google Groups mailing list (or Twitter, lol) first for "open source users" and special support emails for licensed business/pro users. It certainly isn't the impression of "GitHub native discussions".
On the other hand, Microsoft often seems serious about "GitHub native" and winget is certainly in that list of almost every discussion, including some "internal ones" is either in GitHub Issues or GitHub Discussions boards. There's no other mailing list. Things are deeply cross-linked (including into PRs and release notes) and winget looks way more open source and open community than choco on a bunch of little things, despite the disparity in company sizes.
In my experience as a poor and mild open source developer, winget seems welcoming to open community discussion contributions in a way that choco hasn't in way too many years. (I was somewhat involved in early choco. It's commercial licensing pivot lost me in a lot of different, little ways.)
The big thing is that winget requires "proper" MSI or MSIX-backed installers (MSIX, MSI, APPX, and most .exe installers) rather than scripts so given the list you've provided some of what you may need is to better help some of the upstream packages clean up their installers/fix bugs in their installers on Windows. (Package update weirdness sounds like a common class of installer bug, sadly.)
That installer focus is one of the things I like and trust about winget. For the most part it is really easy to verify that winget isn't automating much more than what you could do by hand: it is often grabbing the exact same installer you'd go to someone's website to grab, validating hashes for that installer, then running it (in silent mode). One of the reasons I gave up on Chocalatey years ago was too many "packages" were complex PowerShell scripts and I started feeling like I needed to audit every single one (and every version of it) before running it. Some of the "common" packages were full of opinionated scripts that were doing way too much, and some of the uncommon scripts would sometimes have malware in their scripts (and that may be a late change after years of good scripts, too); I reported it every time I saw it, but at some point you report too many and you lose trust in the whole ecosystem. At the moment trusting winget is still quite a bit easier, even after the burnout I had from choco.
[0] https://github.com/microsoft/winget-pkgs