10.1 When should you take a dependency?

This section is adapted from a blog post and talk by Jim Hester.

10.1.1 Dependencies are not equal

There is a cost associated with adding a dependency that make them not equal.

How can dependencies differ in cost:

  1. Type: base and recommended packages vs. non-CRAN repository packages
  2. Number of upstream dependencies: potentially large number of recursive dependencies
  3. Already fulfilled dependencies: lower costs to recursive dependencies and highly downloaded packages
  4. Install burden: compilation time, binary package size, system requirements
  5. Maintenance capacity: will the package maintainers keep up?
  6. Functionality: outsourcing broadly used functions saves you time

10.1.2 Prefer a holistic, balanced, and quantitative approach

Holistic: Who is the primary audience?

  • useRs will likely have more dependencies installed than other developeRs

Balanced: the trade-off of adding a dependency (install time, disk space, maintenance) comparted to removing a dependency (fewer features, more development by you)

Quantitative: use packages like itdepends and pak to quantify how “heavy” a dependency is

10.1.3 Dependency thoughts specific to the tidyverse

  • Never depend on tidyverse or devtools. Instead depend on the specific package that implements the desired functionality.
  • tidyverse and devtools have large recursive dependencies (\(\geq 100\))
  • Free (low-level) tidy dependences include:
    • rlang
    • cli and glue
    • withr
    • lifecycle
  • R CMD check throws a note for including more than 20 “non-default” package dependencies

10.1.4 Whether to Import or Suggest

10.1.4.1 Imports

  • Must be present at runtime
    • Automatically installs missing packages when your package is installed
    • devtools::load_all() checks too
    • Installed but not attached; to attach, use package::function() within package
Imports:
    dplyr,
    tidyr

10.1.4.2 Suggests

  • Your package can use these packages, but doesn’t require them
    • “Isn’t terribly relevant for packages where the user base is approximately equal to the development team”
    • Does not automatically install missing packages when your package is installed
    • Add for development tasks or to unlock additional functionality (run tests, build vignettes / examples) or rarely needed packages or tricky packages
Suggests:
    ggplot2,
    testthat