search

microsoft / winget-cli

WinGet is the Windows Package Manager. This project includes a CLI (Command Line Interface), PowerShell modules, and a COM (Component Object Model) API (Application Programming Interface).
https://learn.microsoft.com/windows/package-manager/
MIT License
23.15k stars 1.44k forks source link

Add --ErrorAction to standardize bypass flags #3358

Open Trenly opened 1 year ago

Trenly commented 1 year ago

Another thought, what if we include a new parameter "--continueOnError" that when applied would continue the download of the main and dependencies even after a single dependency fails.

I'd propose a more generic -ErrorAction like PowerShell's implementation where WinGet would respect stop, continue, silentlyContinue, inquire, ignore and maybe even suspend. This would probably make the PowerShell cmdlet implementation and could also be useful in other areas too. It could replace the IgnoreUnavailable argument for the import flow, could be used to set the behavior of upgrade all, could be used to continue when depenency installation fails, and would be a great option as a generic parameter for scripting

Originally posted by @Trenly in https://github.com/microsoft/winget-cli/issues/2953#issuecomment-1593548891

Trenly commented 1 year ago

I like this idea of having a parameter that can provide a deterministic experience for the user, that allows the user to determine what they want the experience to be.

Originally posted by @RDMacLachlan in https://github.com/microsoft/winget-cli/issues/2953#issuecomment-1593689824

If we are to replace existing parameters with new ErrorAction parameter, it will be a breaking change. And needs to go through all existing workflows to ensure the experience is accurate. As well as all Com and Powershell work. I would suggest making this a different work item not attached to this download work. For download, I think using --force or a specific flag is good for the purpose.

We also need to think about each different error case by case, some errors are hard stop (installer corrupt, etc), some errors (like dependency download failure for winget download) may let the workflow continue.

Originally posted by @yao-msft in https://github.com/microsoft/winget-cli/issues/2953#issuecomment-1593748567

My opinion would be that the --ErrorAction would only be for the soft-stop errors (ones which can be bypassed) and only in cases where continuing is non-destructive. Destructive errors that can be bypassed (e.g - overwriting pins, forcing an install without converting to upgrade) should still require --force

Trenly commented 1 year ago

[Policy] Breaking-Change

RDMacLachlan commented 1 year ago

Thank you for creating this @Trenly.

RDMacLachlan commented 1 year ago

My opinion would be that the --ErrorAction would only be for the soft-stop errors (ones which can be bypassed) and only in cases where continuing is non-destructive. Destructive errors that can be bypassed (e.g - overwriting pins, forcing an install without converting to upgrade) should still require --force

Agree with your thoughts on the --errorActions however the --force should enforce the actions to be performed.

denelon commented 1 year ago

This should also include work to have "settings" for the default behavior WinGet should use when a user has customized preferences.

Trenly commented 1 year ago

My opinion would be that the --ErrorAction would only be for the soft-stop errors (ones which can be bypassed) and only in cases where continuing is non-destructive. Destructive errors that can be bypassed (e.g - overwriting pins, forcing an install without converting to upgrade) should still require --force

Agree with your thoughts on the --errorActions however the --force should enforce the actions to be performed.

Exactly what I was trying to say, but just didn’t word it right.