You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Is there really a significant benefit in allowing InstallerType on the package-level? #429
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.
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...
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:
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.
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.
Activity
latere-a-latere commentedon Jun 5, 2020
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 commentedon Jun 6, 2020
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 commentedon Jun 8, 2020
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:
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.
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,
InstallerTypeis 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.