Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support object input for overrides #521

Open
mdanish-kh opened this issue Mar 10, 2024 · 1 comment
Open

Support object input for overrides #521

mdanish-kh opened this issue Mar 10, 2024 · 1 comment

Comments

@mdanish-kh
Copy link
Contributor

I wonder if there isn't a need for an object type input something like:

[
  {
    "URL:": "https://example.com/1.exe",
    "Scope": "user",
    "Architecture": "x64",
    "DisplayVersion": "1.2.3_64"
  },
  {
    "URL:": "https://example.com/2.exe",
    "Scope": "user",
    "Architecture": "x86",
    "DisplayVersion": "1.2.3_86"
  },
  {
    "URL:": "https://example.com/3.msi",
    "Scope": "machine",
    "DisplayVersion": "1.2.3"
  },
]

Treat it the same way you would an override for a URL, but then it's a bit more "user-friendly" for autonomous updates, since the workflow could build up a single object to pass in

Originally posted by @Trenly in #516 (comment)

@vedantmgoyal9
Copy link
Contributor

vedantmgoyal9 commented Mar 11, 2024

This kind of input object schema allows greater flexibility, as it not only overrides any existing field but also allows the pass more metadata to wingetcreate which can added to resultant manifests, thus preventing the need to edit manifests manually afterwards.

However, the only downside is that we must specify the common metadata for all installers at each node inside the Installers array. My view is that we can ignore this downside, considering the input object functionality is meant to be used programmatically (i.e. running wingetcreate inside scripts). Also, winget-create moves common fields to the root level at the end of the update function, so it won't affect the resultant manifest. I'll leave it for further discussion.

{
  "ReleaseDate": "2024-08-31", // not exactly an override; a metadata field (to prevent editing manifests manually afterwards)
  "Installers": [
    {
      "InstallerUrl:": "https://example.com/1.exe",
      "Scope": "user",
      "Architecture": "x64",
      "ProductCode": "ExampleSoftware_is1", // to override product code "outside" ARP Entries
      "AppsAndFeaturesEntries": {
        "ProductCode": "ExampleSoftware_is1" // to override product code "inside" ARP Entries
      }
    },
    {
      "InstallerUrl:": "https://example.com/2.exe",
      "Scope": "user",
      "Architecture": "x86",
      "AppsAndFeaturesEntries": {
        // if you want override DisplayVersion, specify it under "AppsAndFeaturesEntries", corresponding to manifest schema itself
        "DisplayVersion": "1.2.3_86",
      }
    },
    {
      "InstallerUrl:": "https://example.com/3.msi",
      "Scope": "machine",
      // suppose arp entries for this installer wasn't present in previous manifest, we're left with two options here:
      // 1. display warning that this field can't be found in previous manifest, and hence can't be overridden
      // 2. treat it as metadata and add it to the new manifest
      "AppsAndFeaturesEntries": {
        "DisplayVersion": "1.2.3.0",
      }
    }
  ],
  // fields in locale manifest are *not* exactly "overrides", just that we can pass some of the metadata through input object
  // so we don't have to edit manifests by hand afterwards
  "Locales": [
    {
      "Name": "en-US",
      "ReleaseNotes": "abcxyz",
      "ReleaseNotesUrl": "https://example.com/releasenotes"
    },
    {
      "Name": "zh-CN", // -> fail when no locale manifest is found, or simply display warning and proceed???
      "ReleaseNotes": "abcxyz",
      "ReleaseNotesUrl": "https://example.com/releasenotes"
    }
  ]
}

Another thing to be noted that --input-object will be mutually exclusive with --urls and --interactive parameters.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants