You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Require EULA/TOS acceptance before download starts. #200
Some packages require a EULA to be accepted before commencing the download of the product. But I have noticed no such functionality is present. There should be an option to provide a EULA/TOS source url or file that will be presented before the download of the file begins that will be accepted by the end user.
My thoughts would be that we can have something like a "EULAUrl" or "TermsURL" that will point to the products EULA or Terms, that will be shown in some kind of pager inside the terminal that will allow accepting or declining. If you accept, download commences and process continues as normal. If declined, just exit.
Also maybe a flag to auto-accept the EULA for purposes of automation.
It would only be problematic if the package you are trying to script against uses the flag, in which case you probably were not scripting that before this anyway no? since it would imply that the package required users to agree to the EULA/Terms before download anyway
I might have accepted the EULA before creating my script, but if I give my script to a friend who has not accepted the EULA, then that might be a problem 😕 .
Another solution might be to add a --accept-licenses flag which auto-accepts the EULAs and prints something like By using the --accept-licenses flag, you agree to the following terms and conditions followed by links to the relevant EULAs. This isn't perfect but would solve the interactivity-in-non-interactive-use-cases issue.
It's kind of what I meant with my last sentence of having a flag for automation.
With proper messaging like krism suggested, it could work well enough. Similar to how Oracle JDK works on Linux even. You have to accept licenses to use it but has a flag for automation to auto accept.
This is mostly to distribute software that requires it, its optional and doesn't need to be used for everything.
Reacted by Matthieu S., Pat Myron, Christopher Addison, Victor Willyams and Ron Kierstead
This is something we have been discussing internally. I do not believe I managed to create an issue for it already. I'm interested in the discussion here. So far it's similar to early thoughts the team had.
If there were a flag in the manifest, the user experience could be improved either with some form of "strict" mechanism requiring user interaction, and / or prioritizing the EULA prompts for download on package set (<- current conceptual name for a collection of packages) initiation. If one were to specify the entire set needed to be 100% unattended, we could fail on manifests that have a EULA required for download.
We have observed EULA prompts prior to download, at install time, and on first launch. Our goals are not to prescribe how software publishers handle their EULAs. We want to focus on providing the best user experience with the client given the various options.
When a EULA is included in a manifest, the user must accept the EULA in order to install the package. A "EULA" key should be added to the manifest schema. A "EULAUrl" key should be added to the manifest schema.
We're going with a somewhat flexible system so verified publishers can customize the fields and to a minor extent, the display behaviors. We would bold the "AgreementLabel". These fields will be part of the locale files so they can be localized.
Validation logic should also look for URLs in text fields to make sure users aren't slipping "bad" URLs by us.
When a user executes show, install, upgrade, or import, the fields should be displayed if they are included in the manifest.
If a EULA field is present, the user must accept the EULA to continue with install, upgrade, or import.
The user may pass an argument to accept the EULA to eliminate required user interaction, but the EULA fields must still be displayed.
The user may pass an argument to accept the EULA to eliminate required user interaction, but the EULA fields must still be displayed.
-a, --accept-agreements
--accept-agreements throws an error:
PS C:\Users\user\Desktop> winget install --id 9N97ZCKPD60Q --source msstore --accept-agreements
Windows Package Manager (Preview) v1.3.431-preview
Copyright (c) Microsoft Corporation. All rights reserved.
Argument name was not recognized for the current command : '--accept-agreements'
Edit: --accept-eula from #1144 doesn't work either.
Edit 2: --accept-package-agreements did the trick!
Should've checked with -? before posting :D
Activity
utybo commentedon May 19, 2020
Wouldn't this be problematic when running winget as part of a script? You're not guaranteed to have an interactive shell
krism142 commentedon May 19, 2020
It would only be problematic if the package you are trying to script against uses the flag, in which case you probably were not scripting that before this anyway no? since it would imply that the package required users to agree to the EULA/Terms before download anyway
utybo commentedon May 19, 2020
I might have accepted the EULA before creating my script, but if I give my script to a friend who has not accepted the EULA, then that might be a problem 😕 .
Another solution might be to add a
--accept-licensesflag which auto-accepts the EULAs and prints something likeBy using the --accept-licenses flag, you agree to the following terms and conditionsfollowed by links to the relevant EULAs. This isn't perfect but would solve the interactivity-in-non-interactive-use-cases issue.daegalus commentedon May 19, 2020
It's kind of what I meant with my last sentence of having a flag for automation.
With proper messaging like krism suggested, it could work well enough. Similar to how Oracle JDK works on Linux even. You have to accept licenses to use it but has a flag for automation to auto accept.
This is mostly to distribute software that requires it, its optional and doesn't need to be used for everything.
denelon commentedon May 22, 2020
This is something we have been discussing internally. I do not believe I managed to create an issue for it already. I'm interested in the discussion here. So far it's similar to early thoughts the team had.
If there were a flag in the manifest, the user experience could be improved either with some form of "strict" mechanism requiring user interaction, and / or prioritizing the EULA prompts for download on package set (<- current conceptual name for a collection of packages) initiation. If one were to specify the entire set needed to be 100% unattended, we could fail on manifests that have a EULA required for download.
We have observed EULA prompts prior to download, at install time, and on first launch. Our goals are not to prescribe how software publishers handle their EULAs. We want to focus on providing the best user experience with the client given the various options.
denelon commentedon Jun 22, 2021
Description of the new feature/enhancement
Some packages require users accept an End User License Agreement (EULA).
Proposed technical implementation details (optional)
When a EULA is included in a manifest, the user must accept the EULA in order to install the package.A "EULA" key should be added to the manifest schema.A "EULAUrl" key should be added to the manifest schema.We're going with a somewhat flexible system so verified publishers can customize the fields and to a minor extent, the display behaviors. We would bold the "AgreementLabel". These fields will be part of the locale files so they can be localized.
Validation logic should also look for URLs in text fields to make sure users aren't slipping "bad" URLs by us.
When a user executes
show,install,upgrade, orimport, the fields should be displayed if they are included in the manifest.If a EULA field is present, the user must accept the EULA to continue with
install,upgrade, orimport.The user may pass an argument to accept the EULA to eliminate required user interaction, but the EULA fields must still be displayed.
-a, --accept-agreements
github-account1111 commentedon Mar 11, 2022
--accept-agreementsthrows an error:Edit:
--accept-eulafrom #1144 doesn't work either.Edit 2:
--accept-package-agreementsdid the trick!Should've checked with
-?before posting :DSquashed 'src/SfsClient/sfs-client/' changes from ff315ecf..6ab78af6