Is there really a significant benefit in allowing InstallerType on the package-level?

[donid]

It seems to me, that having an 'InstallerType'-property on the 'Package'-level does not provide a really significant benefit. I think it makes the development of tools that use the yaml manifests more complicated and error-prone. In my opinion the 'InstallerType'-property on the 'Installers'-level should be the only place for this information.

[latere-a-latere]

I agree with you, however this issue is probably more suited for the winget-cli repo since they also develop the schema over there

[donid]

@marnicgit I always struggle with the decision where to put my issues, but I hope it will be moved, if someone of the team thinks it should be in the other repo...

[lordcheeto]

Essentially, the question is whether there exists a scenario where a piece of software would be packaged into multiple installation types, and I can think of two such scenarios:

1. Many programs are packaged into an installer, as well as standalone binaries in a ZIP file. When ZIP installation eventually receives support, this would allow you to choose which installation type you want.

2. If support is ever extended to other operating systems, they would have different installation types.

In these scenarios, the manifest needs to specify the installation type on the installer definitions themselves, instead of just having a single root type.

Edit: I read your question backwards, I realize now you're asking what benefit there is to having the installer type on the root level. Only real benefit I can think of is conciseness. Support for multiple installers in a manifest is not supported right now, but compared to the other fields, InstallerType is more likely to be shared by many installers, with some overriding the type as in the scenarios above. if at some point you have separate installer entries for different architectures, or languages, that could amount to dozens of lines in the manifest just repeating the installer type for each.