Create #658 - WinGet Download.md

[RDMacLachlan]

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

---

Microsoft Reviewers: Open in CodeFlow

[github-actions[bot]]

@check-spelling-bot Report

:red_circle: Please review

See the :open_file_folder: files view or the :scroll:action log for details.

Unrecognized words (4)

maclachlan occuring roy visualstudiocode

To accept :heavy_check_mark: these unrecognized words as correct, run the following commands

... in a clone of the [email protected]:RDMacLachlan/winget-cli.git repository on the romaclac-spec-WinGet-Download branch (:information_source: how do I use this?):

curl -s -S -L 'https://raw.githubusercontent.com/check-spelling/check-spelling/v0.0.21/apply.pl' |
perl - 'https://github.com/microsoft/winget-cli/actions/runs/4149476265/attempts/1'

Available :books: dictionaries could cover words not in the :blue_book: dictionary

This includes both expected items (407) from .github/actions/spelling/expect.txt and unrecognized words (4)

Dictionary	Entries	Covers
cspell:cpp/src/cpp.txt	30216	26
cspell:win32/src/win32.txt	53509	18
cspell:python/src/python/python-lib.txt	3873	7
cspell:php/php.txt	2597	6
cspell:java/java.txt	7642	5
cspell:python/src/python/python.txt	453	3
cspell:python/src/common/extra.txt	741	3
cspell:django/django.txt	859	3
cspell:typescript/typescript.txt	1211	2
cspell:npm/npm.txt	288	2

Consider adding them using (in .github/workflows/spelling3.yml):

      with:
        extra_dictionaries:
          cspell:cpp/src/cpp.txt
          cspell:win32/src/win32.txt
          cspell:python/src/python/python-lib.txt
          cspell:php/php.txt
          cspell:java/java.txt
          cspell:python/src/python/python.txt
          cspell:python/src/common/extra.txt
          cspell:django/django.txt
          cspell:typescript/typescript.txt
          cspell:npm/npm.txt

To stop checking additional dictionaries, add:

      with:
        check_extra_dictionaries: ''

If the flagged items are :exploding_head: false positives

If items relate to a ...

• binary file (or some other file you wouldn't want to check at all).

  Please add a file path to the excludes.txt file matching the containing file.

  File paths are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your files.

  ^ refers to the file's path from the root of the repository, so ^README\.md$ would exclude README.md (on whichever branch you're using).

• well-formed pattern.

  If you can write a pattern that would match it, try adding it to the patterns.txt file.

  Patterns are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your lines.

  Note that patterns can't match multiline strings.

[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.

[github-actions[bot]]

@check-spelling-bot Report

:red_circle: Please review

See the :open_file_folder: files view or the :scroll:action log for details.

Unrecognized words (3)

maclachlan roy visualstudiocode

To accept :heavy_check_mark: these unrecognized words as correct, run the following commands

... in a clone of the [email protected]:RDMacLachlan/winget-cli.git repository on the romaclac-spec-WinGet-Download branch (:information_source: how do I use this?):

curl -s -S -L 'https://raw.githubusercontent.com/check-spelling/check-spelling/v0.0.21/apply.pl' |
perl - 'https://github.com/microsoft/winget-cli/actions/runs/4177107163/attempts/1'

Available :books: dictionaries could cover words not in the :blue_book: dictionary

This includes both expected items (407) from .github/actions/spelling/expect.txt and unrecognized words (3)

Dictionary	Entries	Covers
cspell:cpp/src/cpp.txt	30216	26
cspell:win32/src/win32.txt	53509	18
cspell:python/src/python/python-lib.txt	3873	7
cspell:php/php.txt	2597	6
cspell:java/java.txt	7642	5
cspell:python/src/python/python.txt	453	3
cspell:python/src/common/extra.txt	741	3
cspell:django/django.txt	859	3
cspell:typescript/typescript.txt	1211	2
cspell:npm/npm.txt	288	2

Consider adding them using (in .github/workflows/spelling3.yml):

      with:
        extra_dictionaries:
          cspell:cpp/src/cpp.txt
          cspell:win32/src/win32.txt
          cspell:python/src/python/python-lib.txt
          cspell:php/php.txt
          cspell:java/java.txt
          cspell:python/src/python/python.txt
          cspell:python/src/common/extra.txt
          cspell:django/django.txt
          cspell:typescript/typescript.txt
          cspell:npm/npm.txt

To stop checking additional dictionaries, add:

      with:
        check_extra_dictionaries: ''

If the flagged items are :exploding_head: false positives

If items relate to a ...

• binary file (or some other file you wouldn't want to check at all).

  Please add a file path to the excludes.txt file matching the containing file.

  File paths are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your files.

  ^ refers to the file's path from the root of the repository, so ^README\.md$ would exclude README.md (on whichever branch you're using).

• well-formed pattern.

  If you can write a pattern that would match it, try adding it to the patterns.txt file.

  Patterns are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your lines.

  Note that patterns can't match multiline strings.

[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.