> 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.)
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
It was the case in the history, 5+ years back. Now big number of packages are not like that. I personally do not use non-embedded packages for office work. See https://github.com/chocolatey-community/chocolatey-packages/...
> 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.