Improvement in data download system

[wcornwell]

Ideal behavior:

USER 1 : casual correction (probably biggest set of users)
Seemless download and use of most current stable version with default arguments without having to specify or learn our versioning system.

USER 2: reproducible behaviour for an analysis
Specify a version and get the exact version from github releases

USER 3: Offline use
Download the data the first time with internet, but then continue to work offline

Other considerations

• Needs to fail gracefully on CRAN when the internet is sporadic (completely on or completely off are the trivial cases)

• Improve speed by moving the cleaning functions to a better place. The primary benifit of this is not the cost of the dplyr steps-- it should allow us to take advantage of some of the parquet arrow efficiencies and be a large performance boost for users

comments? @dfalster @ehwenk

[dfalster]

Agree! Well documented and captured @wcornwell

[ehwenk]

Maybe it should fall under a separate issue, but another change is that is resources is loaded in memory, the loaded version should be the default, rather than resources = load_taxonomoic_resources() that is keyed in as the default for all the functions. @wcornwell

[wcornwell]

probably should tackle as one big re-factor, i'd guess.

in theory it's just

if (exists(obj_name, envir = .GlobalEnv)) {
    message("Status: Loading from Global Environment.")
    return(get(obj_name, envir = .GlobalEnv))
  }
 
  if (file.exists(local_path)) {
    message("Status: Loading from local disk.")
    data <- readRDS(local_path)
    assign(obj_name, data, envir = .GlobalEnv) # put it in memory for next time with a specified name????
    return(data)
  }

but i can't quite work out how to handle the obj_name part, since that's decided by the user previously. if we ask the user for the name, it sort of ends up back in a resources=resources thing, if that makes sense.

We could use the assign bit to choose for the user, and then look for an object with that name? but then that might end up with two objects in memory?

It's not typical R style, but it might be the best solution for this issue? I can't think of anything else...

[dfalster]

Closed via #266