More granular control for winget import

[AdreKiseque]

Description of the new feature / enhancement

WinGet's import command, while convenient in principle, is, to be blunt, extremely limited. There's no support for custom install arguments and, according to the documentation, it doesn't even respect set preferences. This all effectively makes the command a complete non-starter for anyone who needs more than the default install behaviour (which, if you're going through the trouble of automation, you probably do).

I have to assume there's some technical difficulty in implementing this, since it feels like fairly obvious functionality, but I wasn't able to find any issues bringing it up. In any case, this is my feature request to:

• Make winget import respect and use the preferences set in settings.json (with an option to ignore them)
• Allow special preferences to be specified for a particular import manifest in the file and/or when running the command (with override options)
• Allow custom arguments to be specified on a per-package basis inside the manifest file—particularly, the use of the --custom and --override parameters to specify particular arguments for the package installer

Proposed technical implementation details

Arguments such as --no-preferences, --use-set-preferences, --use-file-preferences, --custom-preferences [custom preferences], etc. could be used with winget import to specify behaviour in regards to preferences declared in WinGet's settings, the manifest file and in the command itself. The user could choose to use default behaviour and disregard any preferences set anywhere (current behaviour), override custom preferences set in the json file and use those set in WinGet's settings, or to provide their own preferences to override the others. By default, manifests providing custom preferences would take precedance over preferences in settings, but a preference in settings (ironically) could be used to change this.

A way to allow "stacking" of preferences, for lack of a better term—perhaps WinGet's settings specify a preferred scope while the manifest specifies a prefered architecture; since there's no conflict between these two settings they could both be used. A flag such such as --(dis)allow-stacking could be used to manage this, and it could also be an option within the manifest.

Preference hiearchy of command options > manifest specifications > WinGet settings would likely be ideal.

Custom preferences in the manifest could be specified in the same format as in WinGet's settings.

Keys such as customArguments or overrideArguments could be used for packages within the manifest as analogues to the --custom and --override options in winget install.

[Trenly]

[Policy] Command Import

[denelon]

There have been several other issues related to improvements to the packages.json schema. Most of these have the Command-Import label.

• Support import --scope=machine #3850
• Improve import command with install/add functionality on a per-package basis #3400
• Winget standard settings per package import and export? #2227
• Support install location via import #1582
• Enhance import/export schema to include override values #1512
• Enhancement to winget import command #1273

It's more a matter of priority than technical difficulty. None of these issues other than:

• Enhance import/export schema to include override values #1512
  have received very many 👍to help with prioritization.

[AdreKiseque]

Ah, I'd completely missed there was a tag for it. I'd just tried searching "import" in the issues and didn't find anything. Thanks for showing me!