Alina ran into some trouble with dependencies on Monday. We should be more carefully document dependencies in a way that would prompt user machines to stall or auto-install packages we depend on upon installation or loading of BLEdatatools. Imo best practices would be:
- Prefix any external functions with the double colon syntax, e.g. "readr::read_csv"
- Document the packages the external functions come from in the DESCRIPTION file, e.g.
A quick way to programmatically edit the DESCRIPTION file is to use usethis::use_package("readr").
If the external package is not on CRAN but Github, e.g. bleutils, use usethis::use_dev_package("bleutils", remotes = "BLE-LTER/bleutils" and the output DESCRIPTION would read:
Imports:
bleutils (>= 0.1.0)
Remotes:
BLE-LTER/bleutils
- Export
BLEdatatools functions that we want to be user-facing (so, not the utility-functions) with the @export tag in the header, like so:
# cool useful metadata up here
#' @export
See commit 9939337 for an example of some cleaning up.
Alina ran into some trouble with dependencies on Monday. We should be more carefully document dependencies in a way that would prompt user machines to stall or auto-install packages we depend on upon installation or loading of
BLEdatatools. Imo best practices would be:A quick way to programmatically edit the DESCRIPTION file is to use
usethis::use_package("readr").If the external package is not on CRAN but Github, e.g.
bleutils, useusethis::use_dev_package("bleutils", remotes = "BLE-LTER/bleutils"and the output DESCRIPTION would read:BLEdatatoolsfunctions that we want to be user-facing (so, not the utility-functions) with the@exporttag in the header, like so:See commit 9939337 for an example of some cleaning up.