Questions on how this works, verification, install options, etc

[MythreyaK]

I've had a few questions on some of the aspects of how WinGet works. I went through the documentation, but had a few questions unanswered. I'm still a beginner, so any links to docs, examples would be really welcome!

1. How are apps vetted? I think it's manual verification, where when a new .yaml is added, it is checked to see it's from the original publisher, and doesn't link to shady binaries.
2. How are some publisher specific options handled? Are they set to 'sane defaults'? For example, in Python, I'd rather do a user-install without the documentation, and have itself added to path, and disable path limit. Would be nice to see what the defaults are, and way to set those options.
3. Package updates are on the roadmap, how would this deal with 'new install options' that are added to an installer?
4. Would these installers work in a non-GUI env, such as a docker container? I guess it depends on the installer specified for a package.
5. Any thoughts on dependency management?

Thanks!

[denelon]

We have quite a bit of static analysis performed on the installers to reduce the chances of malware ending up in the packages referenced by the manifests. There is some manual validation to check that the official source for a package is referenced, and the other meta-data is valid.

You can look at a manifest to see what's configured. You can also use the override argument to apply your own preferences to installers.

We have some additional YAML keys on the table to look at upgrade scenarios. What kinds of new install options are you thinking of?

We'd like to have silent unattended install possible for packages to support the docker container example. Additional meta-data would be required for us to accept packages that require an attended install. Many packages are declined if they require user interaction currently.

Dependency is one of the features on the roadmap. We will install or prompt if they are required and we can't install them. At this point, we're not looking to remove dependencies when a package is uninstalled.

[MythreyaK]

By new install options, I mean in case the installer changes to add some feature. Notable example is Git for Windows, where every few releases, new install options are present.

I find myself comparing this to other package managers such as apt-get, pacman, etc, so perhaps I'm biased that way. In those cases (from what I understand), a core set of maintainers manage and workout package dependencies so that most play nice with each other. I'm not sure if that model will work here, since (again, from my limited understanding) most packages might be self-contained, or bundle the dependencies with them. Since you said dep-management is on the roadmap, with win-get, will this model change, to more actively use existing dependencies and just declare them in the installer or the manifest instead of bundling them?

Thank you for answering my questions!

P.S Is it okay if I ask some novice questions here, or is this discussion form here developer and maintainer focused?

[denelon]

Dependencies haven't finalized yet. We're looking at how we're going to handle the differences between MSIX dependencies vs. Win32 dependencies. Generally we see them as Windows libraries, other packages in the same source, and other dependencies like languages or runtimes where there might be many to chose from. Windows Features may also become a form of dependency. They will be added to manifests in the next version of the manifest syntax so the package manager can install them for you. We haven't locked on what updating dependencies over time would look like just yet.