[R-pkg-devel] Handling Not-Always-Needed Dependencies?
Thomas J. Leeper
thosjleeper at gmail.com
Tue Aug 2 18:26:03 CEST 2016
I have a fairly open-ended question about the handling of package
dependencies that is inspired by the precise distinction between
"Depends", "Imports", and "Suggests" listed in DESCRIPTION.
Some background, as I understand it: Prior to requiring package
namespaces, we listed package dependencies in "Depends" because the
required package had to be (1) installed and (2) on the search path in
order to access its functions. After introducing and requiring
namespaces, there are very few circumstances in which "Depends" is
needed because functions from the required package can either be
imported (via "Imports" and NAMESPACE) and/or referred to using the
`pkg::fun()` style. "Suggests" packages are maybe needed for examples,
vignettes, etc. but are not installed by default via
`install.packages()`, so are not guaranteed to be available.
Some observations:
1. "Depends" seems to be less useful than before, except in rare cases
where a package needs to be (a) installed, (b) loaded, and (c) on the
search path. Imports covers most package dependency use cases.
2. There is a gap in functionality between "Imports" and "Suggests".
Sometimes there is a need for functions that should be available
(i.e., installed) but do not need to be loaded or imported because
they are rarely used (e.g., graphing functions). Importing the
functions adds bloat but only putting their package in "Suggests" does
not guarantee availability when, for example, calling
`requireNamespace()` or `require()`.
Suggestion:
Might it be useful to have a category between "Imports" and "Suggests"
that covers packages that should be installed but not imported?
This could be done by changing `install.packages()` to cover
"Suggests" by default, changing the meaning of "Depends" and
"Imports", or adding a new category to DESCRIPTION.
I am interested in hearing your thoughts on this issue.
Best,
-Thomas
Thomas J. Leeper
http://www.thomasleeper.com
More information about the R-package-devel
mailing list