Set default to [y] for downloading

[juliohm]

Currently when we just press ENTER, the question is asked again. Perhaps ENTER could mean [y] by default.

[oxinabox]

Seems reasonable.
Enhancement would need to be made here to add a option for a default,

[juliohm]

I was thinking if the question should timeout as well and return with the default answer of [y]? Or perhaps this question should not be asked at all? In most use cases I can think of, the user wishes to download the dataset if it is not already downloaded. It seems that [n] is a very unlikely answer. What do you think? What use case you have in mind where the user will answer no?

[oxinabox]

What use case you have in mind where the user will answer no?

Some things actually have a lisence agreement you have to agree to here.
One example is Open Research Corpus used in this blog post.
In general, requiring user acceptance is what MLDatasets.jl did before its whole downloaading functionality was generalized into this package

I would class automatically agreeing as a breaking change.
Unless it is opt-out of requiring the message to be agree'd to at the registration block.

The user can already automatically accept all by setting the DATADEPS_ALWAYS_ACCEPT enviroment variable

[juliohm]

Yes, it would be nice to be able to opt-out from the question in the registration block. It facilitates triggering experiments on remote machines without interactivity.

[knuesel]

I would like to argue too for removing the download confirmation. On the technical side, it interferes with automation and can cause hard-to-debug issues in certain environments like IJulia, see devmotion/PalmerPenguins.jl#9 for an example (and for the user of a package like PalmerPenguins, that happens to use DataDeps, it's rather difficult to discover DATADEPS_ALWAYS_ACCEPT).

On the non-technical side, I just find the prompt annoying... Admittedly not the most convincing argument but I guess that's the real motivation for me to write here 😊. The thing is I don't think the prompt is necessary (at least in the vast majority of cases) so it really bugs me to have this "artificial" friction in the workflow.

It's true that many datasets have license agreements, but that's also the case of most software. Even for BSD or MIT licensed packages, the user has no right to use them unless they agree to the license. Thankfully, we don't have confirmation prompts each time we install packages... Instead, it's understood the user agrees to the license when they decide to install the package. It's the user responsibility to check that the license allows for what they want to do with the package, and it's the package author responsibility to document all the relevant licenses (for example if they include a dataset with a specific license).