As part of the task force to help improve decision-making around taking on dependencies, we have arrived at a checklist that could be used. The checklist essentially sums up a lot of the recommendations in the blueprints chapter on dependencies. I am going to post it here for further input and to discuss next steps. We could potentially merge this into the section, if deemed useful.
Considerations for taking on a dependency
Have you requested code review to check if the dependency can be replaced with a base R implementation?
Have you generated a dependency graph (using pak::pkg_deps_tree() for example) to understand the dependency tree?
Will your package be submitted to CRAN? If so, is this chosen dependency on CRAN? (This is a CRAN policy. See here)
Has the dependency had major releases?
Is the dependency used extensively in the core functionalities of the package?
Is the dependency used by only a small portion of your application, rather than being used throughout?
Does removing the dependency require minimal changes to your codebase?
Does the package have an active and responsive maintainer?
NB: This depends on your own judgement of whether the package needs active maintenance.
Does the package require a system software, for example, docker, clang, etc?
Does the dependency have other dependencies that will be imported as well?
As part of the task force to help improve decision-making around taking on dependencies, we have arrived at a checklist that could be used. The checklist essentially sums up a lot of the recommendations in the blueprints chapter on dependencies. I am going to post it here for further input and to discuss next steps. We could potentially merge this into the section, if deemed useful.
Considerations for taking on a dependency
pak::pkg_deps_tree()for example) to understand the dependency tree?cc: @bahadzie @jd-otero @davidsantiagoquevedo