Dvc.org: term: review "download" in the context of get and import commands, et al.

[jorgeorpinel]

(Perhaps also dvc fetch, dvc checkout? Look for others.)

This is because when the data source for an of these commands is located in the same file system where the command is running, there may be no downloading involved, bust simply a copy (or reflink).

For example (and where this issue came from): dvc get {local_repo_url} path will at some point just copy from the external repo's cache dir instead of going to its remote storage (see iterative/dvc/issues/2599) but even now, if that repo has a local remote configured, then the operation is a copy. And regardless of the implementation detail (whether its an HTTP GET request, S3 API, cp --reflink, etc.), to the user, getting a file from another local file system repo doesn't "feel like" downloading anything.

See also discussions in https://github.com/iterative/dvc/pull/2837#pullrequestreview-323201818 and https://github.com/iterative/dvc.org/pull/821#pullrequestreview-324403325.

Possible solutions envisioned so far:

• Just use "download". The copy scenarios are edge cases and it may not be worth it complicating docs with possibly confusing and longer phrases to catch all possible behaviors.
• Use "download/copy" and/or "copy or download" appropriatly for maximum correctness.
• Use more general terms like "obtain" or "retrieve" when ambiguity is needed (currently used in dvc get cmd ref. per #821).

p.s. this will affect some output strings in the iterative/dvc repo which will need it's own PR.

[shcheklein]

👍 for one simple term for the sake of simplicity. I'm fine with download + some explanation in the command reference.

[jorgeorpinel]

Any opinion on this @danihodovic, @efiop? Thanks.

[danihodovic]

I have no strong opinions as long as the docs are consistent.

[efiop]

@jorgeorpinel I agree with @shcheklein and @danihodovic 🙂