finalize API

[pearsonca]

My opinionated takes:

• nix the git / python installation. not required for core capabilities, should be responsibility of capability modules that require them.
• I would argue remove EPIESTIM from API (and create a separate package for it and hand off to Cori et al); this shows a way forward for other connector packages, has EpiEstim as on-release available, but gets us out of the business of managing that requirement. Offering EPISTEM as part of the API as an optionally-supported approach is explicitly undesirable for any kind of long term maintainence plan.
• get_data as a wrapper around epidatr seems ...suboptimal. epidatr is a heavy weight dependency, but has a more complicated interface than desired for users - what we really want long term is something more shim like. Plausible to have a relatively general-purpose data transformer, however.
• to_respilens should be owned by respilens, not this package (as should other to_X formats). Maybe similar to EPIESTIM, we spin that off into a standard sibling package.
• new API requirement: I think a method which can introspect available sibling packages and report them to user (e.g. you have fable.epiestim, fable.whizzbang installed => can use those with this, see ?whatever for their signatures; maybe even apply same scan to CRAN namespace for potential packages that might be supported)

Also needed #63

[shauntruelove]

get_data -- agree epidatr is very heavy weight and more complicated than desired. What is meant by a "shim"? and how would a data transformer do what this function is doing?

to_respilens -- At some point we could argue every component could be spun off as it's own helper package, so I feel like we should just integrate this since this is in house as well

[pearsonca]

get_data -- agree epidatr is very heavy weight and more complicated than desired. What is meant by a "shim"? and how would a data transformer do what this function is doing?

a shim would be some implementation of facade pattern (like this function), but that doesn't bring in that dependency into this library (unlike the function).

if there were a vignette showing a function for using epidatr for this kind of approach (probably even just this function), that's 1) more flexible / reusable long term (users actually see the guts of the function, and can potentially use) and 2) lower maintenance burden (epidatr changes? we can drop a vignette / declare it OBE without us breaking peoples code).

the "general" transformer suggestion was probably a bad one. i think people can generally handle renaming etc their input data to match a spec. but i could see value in a vignette generally that shows getting from some common data sources of interest (e.g. epidatr, but also some others) into properly formatted for this tool (e.g. having one solution that's roughly the get_data function for interacting with epidatr, another section showing renaming some columns, or joining data together, etc).

to_respilens -- At some point we could argue every component could be spun off as it's own helper package, so I feel like we should just integrate this since this is in house as well

putting it another way then: respilens already have a hubverse output transformer. seems like we should be pointing people to use that, rather than tightly coupling to the respilens API by reimplementing their transformer. If the problem is "python bad", then that problem is really "we can't drag and drop csv into respilens site". which: fair enough!

but: the respilens folks have as an issue to fix that on their end (ACCIDDA/RespiLens#121). Rather than introducing a weird maintenance requirement here, we should do the work in the right place.