"AppGet uses YAML files instead of scripts; we call them manifests. Using data over scripts just seemed like a much better choice."

So it's an opinion, one that the WinGet team decided to go with as well. Okay... not sure that's massively compelling just because the author says so but I'm willing to be convinced. I guess I need to go back and dig deeper on this scripting being referenced in Chocolatey: isn't it just powershell scripting?

In general it's easier to verify the security of the installation (not the code itself) if the package is configured via manifest instead of script. That's because you've preemptively restricted what the installation could possibly do, at the cost of flexibility. There are also some other specifics that are easier to implement via manifest than asking maintainers to implement via script, like supporting private app repository hosting (common enterprise feature). I suspect that's why WinGet went with AppGet's approach instead of Chocolatey.

Yeah and recently a lot of Chocolatey scripts are calls to a number of standard helpers for various types of installers. Not a whole lot of arbitrary commands being used.

Having something like YAML seems cleaner than the Chocolatey approach, but there are almost 8,000 Chocolatey packages and it works pretty well. Implementation > architecture here.

Yeah it's very dubious to me that YAML is the better approach, at least from the perspective of the average enterprise looking for Windows package management tooling.

There are still too many nasty installers out there, I'd be very worried about the ability to do what I need without a full scripting language at hand.

You can have an approach that is YAML with scripting where necessary. There are so many packages that fit into one of the standard Chocolatey package setups (exe, msi, msu, vsix, zip).

https://chocolatey.org/docs/helpers-install-chocolatey-packa...