Disambiguate data get [dataset] and data get from Datafile

[btc]

@jbenet,

What are your thoughts on disambiguating (1) fetching a single dataset from (2) fetching a collection from a Datafile? Is this something you've already considered and made a decision to avoid?

Proposing the following api modification:

$ data install
# downloads datasets given Datafile

This would pave the way for users to explicitly specify a Datafile without excessively overloading the get command.

$ data install [-arg to specify datafile] Datafile.staging

[jbenet]

Yeah, data install is similar to what people expect from other package managers.

Have considered (but not settled on what the right approach is):

• adding data install for dependencies (as you propose)
• keep them the same, but rename data get to data install
• use a flag, like data get --deps or data install --deps
• use a datafile arg, like data get Datafile or data install Datafile
• use a datafile arg w. flag, like data get --deps Datafile or data install --deps Datafile

It might make sense to differentiate data get and data install as you propose, but semantically get and install are not that obviously different. Is there a more obvious phrasing for the "install dependencies listed in the Datafile" idea? Let's keep in mind that target users are not all software engineers, but scientists in other fields that write programs. In my view, intuitive naming >> traditional naming. Thoughts?

Affects #20.

[btc]

This sort of data management is somewhat unprecedented. People install programs and install software, but they download and get data. People don't typically say they're installing data.

On the other hand, data is the first of its kind. There is an opportunity to set the tone and define the new norm. Perhaps data installation is a thing.

Perhaps the tool should ease adoption for new users with something sensible, but ultimately take an authoritative stance.

It's unclear to me. I don't mean to distract you with this non-critical concern. Perhaps this is just something to keep an eye on as the API matures.