Skip to content

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

Closed

Description

@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.

Activity

  1. latere-a-latere commented on Jun 5, 2020

    @latere-a-latere
    Contributor

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

  2. donid commented on Jun 6, 2020

    @donid
    Author

    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...

  3. lordcheeto commented on Jun 8, 2020

    @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.

  4. ghost added
    Needs-TriageIssue needs to be triaged
    on Jun 16, 2020
  5. added
    Area-ManifestThis may require a change to the manifest
    Issue-FeatureThis is a feature request for the Windows Package Manager client.
    and removed
    Needs-TriageIssue needs to be triaged
    on Jun 16, 2020
  6. added this to the milestone on Jun 16, 2020
  7. locked and limited conversation to collaborators on Jun 12, 2023
  8. converted this issue into a discussion #3333 on Jun 12, 2023
  9. modified the milestones: , v1.6 Client on Jun 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Area-ManifestThis may require a change to the manifestIssue-FeatureThis is a feature request for the Windows Package Manager client.

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions