Dynamically build DESCRIPTION dependencies list

When developing a package, I find the R CMD check step doesn't check as strictly as I'd like. I often will add some pkg::func() call while developing and forget to include it in the DESCRIPTION's Include list. Sometimes an error or warning is thrown (it depends on where that code lives ... e.g. if inside an R6 class, effectively no warning is ever raised), but because I almost always have pkg installed already in my development environment, no error is raised during the check step.

The renv package already does a pretty good job scanning through project directories to build lists of all dependencies. Does anything like this exist to folks' knowledge for auto-generating a compact list of the first-level dependencies (as opposed to renv's fully-closed complete list) used by a package? Such a list could then be used as a reference list for the developer to build out the Imports, Depends, Suggests, Enhances DESCRIPTION sections.

I know that the usethis package already has some provisioning for this idea with use_package(), but this again relies on the developer remembering at some function's first usage in code that it comes from a not-already-referenced-in-DESCRIPTION package.

If this doesn't already exist, this seems like it'd be a super-helpful tool to include in devtools (or other upstream package), and likewise it also seems like it'd be a simplification of the already-working renv dependency-scanning implementation.

LOL well it appears renv already has a function that does this: renv::dependencies().

1 Like

You may want to look at {attachment}, and in particular att_amend_desc().
This runs roxygen, extract all dependencies in your package and update the DESCRIPTION file in the appropriate field (Imports, Suggests), depending where the package was found (R/, vignette, tests).
Find {attachment} full documentation here: Deal with Dependencies • attachment

1 Like

You could also use CI to run R CMD check in a fresh environment which will cause errors with missing packages and other environment-specific issues, the rOpenSci Guide has a section on how & why to set this up: Chapter 2 Continuous Integration Best Practices | rOpenSci Packages: Development, Maintenance, and Peer Review

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

If you have a query related to it or one of the replies, start a new topic and refer back with a link.