Wrapper functions: one-shot calc_covariates or proc_covariates & calc_covariates?

[sigmafelix]

Old calculate_covariates used path, sites, id_col as common arguments. This approach made sense as previous calc_* functions were a combination of processing (or importing) and calculating functions. However, the wrapper will not work as we split these into two parts, which makes me think about calc(ulate)_covariates wrapper function refactoring ideas.

• From the start: Do we need a wrapper function?
• If we agree on the need of a wrapper function, I think there are two approaches to refactor calc_covariates:
  • Add process_ parts inside the current calculate_covariates for convenience
  • Add process_covariates besides calculate_covariates for consistency

To deal with data-specific arguments in a wrapper function, I found that the combined use of ellipsis argument (...) and rlang::inject(foo(!!!args)) is helpful for development, which is reflected in my 0.1.0 PR #13 .

[mitchellmanware]

My original thoughts were the second option, where the workflow for all data sources is download_data() ... process_data() ... calculate_covariates(). Although the intermediate processing step may simply be reading in the data with terra::rast(), I think the consistency is helpful (at least for me).

Why would process_data() and calculate_covariates() wrapper functions not work the same as in data_download()? The data download wrapper function is able to accept a range of arguments based on the underlying specific function, so how would the others be different?

[sigmafelix]

@mitchellmanware Wrapper functions for process_* make sense. I look forward to finding that the ongoing PR is finalized then I will work on adding a wrapper.

[sigmafelix]

process_covariates is in progress along with adding process_sedac_groads. Will make a PR as soon as I finish adding these.

[sigmafelix]

Resolved by #26 .