[Rd] importing namespaces from base packages
dusa.adrian at unibuc.ro
Tue Mar 13 08:17:08 CET 2018
On Mon, Mar 12, 2018 at 2:18 PM, Martin Maechler <maechler at stat.math.ethz.ch>
> Is that so? Not according to my reading of the 'Writing R
> Extensions' manual, nor according to what I have been doing in
> all of my packages for ca. 2 years:
> The rule I have in my mind is
> 1) NAMESPACE Import(s|From) \
> ............................ <==> DESCRIPTION -> 'Imports:'
> 2) .. using "::" in R code /
> If you really found that you did not have to import from say
> 'utils', I think this was a *un*lucky coincidence.
Of course, the importFrom() is mandatory in NAMESPACE otherwise the package
does not pass the checks.
The question was related to the relation between the packages mentioned in
the NAMESPACE and the packages mentioned in the Imports: field from
For instance, the current version 3.1 of package QCA on CRAN mentions in
Imports: venn (≥ 1.2), shiny, methods, fastdigest
while the NAMESPACE file has:
importFrom("utils", "packageDescription", "remove.packages",
importFrom("stats", "glm", "predict", "quasibinomial", "binom.test",
"cutree", "dist", "hclust", "na.omit", "dbinom", "setNames")
importFrom("grDevices", "dev.cur", "dev.new", "dev.list")
importFrom("graphics", "abline", "axis", "box", "mtext", "par", "title",
There are functions from packages utils, stats, grDevices and graphics for
which the R checks do not require a specific entry in the Imports: field.
I suspect because all of these packages are part of the base R, but so is
package methods. The question is why is it not mandatory for those packages
to be mentioned in the Imports: field from DESCRIPTION, while removing
package methods from that field runs into an error, despite maintaining the
package in the NAMESPACE's importFrom().
> There are places in the R source where it is treated specially,
> indeed, part of 'methods' may be needed when it is neither
> loaded nor attached (e.g., when R runs with only base, say, and
> suddenly encounters an S4 object), and there still are
> situations where 'methods' needs to be in the search() path and
> not just loaded, but these cases should be unrelated to the
> above DESCRIPTION-Imports vs NAMESPACE-Imports correspondence.
This is what I had expected myself, then the above behavior has to have
It is just a curiosity, there is naturally nothing wrong with maintaining
package methods in the Imports: field. Only odd why some base R packages
are treated differently than other base R packages, at the package checks
University of Bucharest
Romanian Social Data Archive
Soseaua Panduri nr. 90-92
050663 Bucharest sector 5
[[alternative HTML version deleted]]
More information about the R-devel