It seems that they are defined in tools/R/check.R. For instance, line 363-364 says:

    ## The default set of packages here are as they are because
    ## .get_S3_generics_as_seen_from_package needs utils,graphics,stats

and then on lines 368 (Windows) and 377 (other OS) it has:

So these pass R CMD check and are an "industrial standard". Changing this will be break half of CRAN packages.

Cheers, Jari Oksanen

On 13/03/18 13:47, Martin Maechler wrote:
Adrian Dușa <>
     on Tue, 13 Mar 2018 09:17:08 +0200 writes:

     > On Mon, Mar 12, 2018 at 2:18 PM, Martin Maechler 
     > wrote:
     >> [...]
     >> 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 
     > does not pass the checks.
     > The question was related to the relation between the packages mentioned 
     > 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
     > the DESCRIPTION:

     > Imports: venn (≥ 1.2), shiny, methods, fastdigest

     > while the NAMESPACE file has:

     > import(shiny)
     > import(venn)
     > import(fastdigest)
     > importFrom("utils", "packageDescription", "remove.packages",
     > "capture.output")
     > importFrom("stats", "glm", "predict", "quasibinomial", "binom.test",
     > "cutree", "dist", "hclust", "na.omit", "dbinom", "setNames")
     > importFrom("grDevices", "dev.cur", "", "dev.list")
     > importFrom("graphics", "abline", "axis", "box", "mtext", "par", "title",
     > "text")
     > importFrom("methods", "is")

     > There are functions from packages utils, stats, grDevices and graphics 
     > 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 
     > to be mentioned in the Imports: field from DESCRIPTION, while removing
     > package methods from that field runs into an error, despite maintaining 
     > package in the NAMESPACE's importFrom().

Thank you, Adrian,  for clarification of your question.
As a matter of fact, I was not aware of what you showed above,
and personally I think I do add every package/namespace mentioned in
NAMESPACE to the DESCRIPTION's  "Imports:" field.

AFAIK the above phenomenon is not documented, and rather the
docs would imply that this phenomenon might go away -- I for one
would vote for more consistency here ..


     >> [...]
     >> 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
     > another explanation.
     > 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
     > stage.

     > Thank you,
     > Adrian

     > --
     > Adrian Dusa
     > University of Bucharest
     > Romanian Social Data Archive
     > Soseaua Panduri nr. 90-92
     > 050663 Bucharest sector 5
     > Romania

     > [[alternative HTML version deleted]]

______________________________________________ mailing list

______________________________________________ mailing list

Reply via email to