Support object input for overrides

[mdanish-kh]

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]

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 it 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 update workflow, 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.

@ryfu-msft @yao-msft what are your thoughts on this?