Make InstallationNotes flow-dependent

[Trenly]

Description of the new feature / enhancement

Allow different messages to be shown on Install, Upgrade, and Uninstall.

Proposed technical implementation details

To keep manifests clean, I would prefer the field be changed to an object rather than adding new manifests fields, although I suppose either would work. With the 2020-12 schema, it might also be possible to allow for backwards compatibility to prevent this from being a breaking change.

InstallationNotes:
 PreInstall: This message is shown before a package is installed
 PostInstall: This message is shown after a package is installed
 PreUpgrade: This message is shown before a package is upgraded
 PostUpgrade: This message is shown after a package is upgraded
 PreUninstall: This message is shown before a package is uninstalled
 PostUninstall: This message is shown after a package is uninstalled

[stephengillie]

I'm assuming this would be displayed as console messages in the same window as WinGet was launched. This could be a good way to give interactive and other installer/uninstaller instructions. Possibly even give reboot notice.

[Trenly]

I'm assuming this would be displayed as console messages in the same window as WinGet was launched. This could be a good way to give interactive and other installer/uninstaller instructions. Possibly even give reboot notice.

Yes, basically the same way InstallationNotes work currently, but expanding the functionality

[denelon]

The "pre" activity notes seem like they make sense in terms of a user at the CLI expecting a prompt.

In the context of a WinGet Configuration the mode would logically be "--disable-interactivity". We would expect WinGet to fail in those cases rather than expecting a prompt (unless "--force" was specified).

Users could still pass "--force" to tell WinGet they know what they are doing and it would essentially override "--disable-interactivity".

These notes are in reply to work being done to improve the "Deny" behavior for upgrade.

Several packages have different variations of reasons the upgrade behavior should be conditional:

Discord.Discord - Has an auto-updater built into the application, and doesn't update the version displayed in ARP. Installing a newer version erases user settings

Note

This has been fixed by Discord.

Anaconda.Miniconda3 - Has a special upgrade program "Conda" for upgrading. The only way to upgrade through winget is to uninstallPrevious, which erases user settings

Chocolatey.Chocolatey - Installer is "Install-Only", and the application self updates

MSYS2.MSYS2 - Has a default install location and cannot be installed over,
msys2 cannot be uninstalled silently and unstalling previous version will remove all msys2 packages and user settings

[denelon]

In the event any of the "pre" notes are present in the manifest, a user on the CLI would be prompted before they continue.

Any of the "post" notes would simply be informative.

In our validation envronment, we would likely either automate using "--force" or some other argument.

[MattHyman]

The GDK would be a great candidate for PreInstall Installation Notes per our need to configure the target VS instances with the right workloads.

[Karl-WE]

I like that and still would appreciate a more verbose / funky output as I have suggested once in #4057 (apt-get alternative).
Their output is marvellous,

On the topic
Where would the output come from? Automated? Part of comments in the YAML?
If YAML we may not allow URLs in these comments as with PS 7 and Terminal these are clickable items.

"To keep manifests clean, I would prefer the field be changed to an object rather than adding new manifests fields,"
Good point.

--force should still show these notes but avoid blocking. Maybe we can also skip these with --force and only show them with --force --verbose, but that might result into an unexpected syntax / UX, when these notes are shown, if --force is not specified.
Coming from PowerShell showing installation notes only with --verbose would feel natural.

Hence it is often used in PS for debug reasons, I doubt that many users will specify a verbose parameter to receive installation notes. So efforts on this might result into low adoption / usage.
Cats bites its tail.

[Karl-WE]

"Several packages have different variations of reasons the upgrade behavior should be conditional:"

lately had user within my family which had a lot of tools for 3D printing supported by winget but these apps on upgrade install side-by-side, unexpectedly. But it is by design and intended by the developers.

[denelon]

Yeah, I added Ultimaker Cura way back when this was super early preview and ran into the side-by-side challenges. I didn't want the old one removed because I had to copy all the materials data over manually from version to version. Fortunately, we're working on better support for side-by-side and that should come out in the next preview. We do have some conditional arguments to "uninstall previous", but I wouldn't want to do that until I had the new one installed, and with two versions installed, WinGet doesn't know how to target the earlier version (until this next release comes out). I'll be testing with that.

[Karl-WE]

Can try to find more examples