Create #658 - WinGet Download.md

[RDMacLachlan]

• I have signed the Contributor License Agreement.
• This pull request is related to an issue.

---

Microsoft Reviewers: Open in CodeFlow

[Trenly]

I would think that the ability to download only would make more sense in the context of cache management. This discussion around cache management even includes the Download only request. I think we should assess if cache management makes more sense here to decrease code complexity

[yao-msft]

I would think that the ability to download only would make more sense in the context of cache management. This discussion around cache management even includes the Download only request. I think we should assess if cache management makes more sense here to decrease code complexity

We had some internal discussions about this. Since we already moved installer download to temp, there's not a lot more benefit of doing cache management. For customers wanting to do offline installation, we think explicit winget download is the way to go. We had customer asks that they need to manage a group of devices with limited network access, so winget download would be an option for this.

[yao-msft]

By the way, I just thought of something, do we deal with dependency packages for download? If yes, what will be the behavior and layout (folder structure, filename, etc)

[RDMacLachlan]

By the way, I just thought of something, do we deal with dependency packages for download? If yes, what will be the behavior and layout (folder structure, filename, etc)

We will need to handle dependency packages.

[RDMacLachlan]

Need to include an option for only downloading the apps and not the license file.

Does having a similar flow for License file only make sense?

[yao-msft]

Does having a similar flow for License file only make sense?

No, licensing requires a specific package (content id), licensing call must come after download call.

[RDMacLachlan]

Does having a similar flow for License file only make sense?

No, licensing requires a specific package (content id), licensing call must come after download call.

I was thinking about the scenario of when the app downloads but the license file fails to download. Should the administrator then re-download the app again to get the license file.

[RDMacLachlan]

Thinking about the use of --download-directory, would it make more sense for us to use "--Location", or "--Path"?

[RDMacLachlan]

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.

[Trenly]

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

[RDMacLachlan]

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

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.

[yao-msft]

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.

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.

By the way, the reason I would like dependency download to fail the workflow is for consistency. Looks like in winget install flow, a dependency download failure will cause main package to fail to install. In winget download flow, a dependency download failure may be ok if user desires.

[Trenly]

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.

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.

By the way, the reason I would like dependency download to fail the workflow is for consistency. Looks like in winget install flow, a dependency download failure will cause main package to fail to install. In winget download flow, a dependency download failure may be ok if user desires.

I'll make a separate issue for the proposed ErrorAction

[vedantmgoyal9]

I guess the download command got implemented, and the spec never made to the repo.

[yao-msft]

I guess the download command got implemented, and the spec never made to the repo.

Yep, we just noticed yesterday and Ryan is working on updating it to match the final implementation. Thanks.