As a user I've enjoyed using winget to fetch and manage command line utilities on Windows. So when looking at options for my own server project I was interested in trying this deployment option.
One thing I'm I appreciate is the ability for a project Manifest to define a package from a standalone executable, or a zip file with the executable included. No mucking about with installer executables or msi as a maintainer.
The way winget packages are managed reminds me of how FreeBSD manages all their package recipes in a monolithic source control repository named ports. For winget this is done as a Git repository of an absolutely massive, overwhelming scale.
The first rule is, you don't check out this Git repository. You'll need to deal with sparse checkouts and never focus your eyes too closely at the results. So far I've had good luck cloning my fork with
git clone --depth 1 --filter=blob:none --sparse https://github.com/my_fork_owner/winget-pkgs
git sparse-checkout set manifests/p/ProjectStartingWith_P
From there I can copy the manifest files into the proper versioned subdirectory. Then git add and git commit and git push like regular.
But then the "real work" begins; a pull request of your fork back to the main repo. Maintaining such a thing is somewhat unthinkable. What army of volunteers or workers could ever manage such a thing?
The repository is maintained by a fleet of Github Actions that manage CLAs, validate submissions, run virus scanners, and a deep array of byzantine processes. These manage a collection of labels on the pull request. Things like New-Package, Needs-Attention, and the dreaded Validation-Defender-Error.
Maintainers then triage the pull requests based on these labels. Generally using predefined response templates Github provides.
In my case my package is fairly stuck. It seems Rust compiled binaries have a tendency to trigger the Defender virus checks. What makes this annoying is that a local Defender scan finds no problem with my binary. I also submitted a false positive check to the MSI team and the results also came back clean.
I'm somewhat stuck waiting for the winget process to potentially re-evaluate my binary for release (or grant some type of exception?).
The massive scale of it all is both impressive and a bit intimidating. Also a bit frustrating as my problems seem lost in an ocean of other projects and packages all vying for similar attentions.
In the meantime, keep rooting for Pull Request #422040 finding a road to release.
Top comments (0)