Open Trenly opened 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
[Policy] Breaking-Change
Thank you for creating this @Trenly.
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.
This should also include work to have "settings" for the default behavior WinGet should use when a user has customized preferences.
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.
I'd propose a more generic
-ErrorAction
like PowerShell's implementation where WinGet would respectstop
,continue
,silentlyContinue
,inquire
,ignore
and maybe evensuspend
. 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 scriptingOriginally posted by @Trenly in https://github.com/microsoft/winget-cli/issues/2953#issuecomment-1593548891