[Rd] importing namespaces from base packages

[Jari Oksanen]

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:
     "R_DEFAULT_PACKAGES=utils,grDevices,graphics,stats"

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 <dusa.adrian at unibuc.ro>
>>>>>>      on Tue, 13 Mar 2018 09:17:08 +0200 writes:
> 
>      > On Mon, Mar 12, 2018 at 2:18 PM, Martin Maechler <maechler at stat.math.ethz.ch>
>      > 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 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
>      > DESCRIPTION.
> 
>      > 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.new", "dev.list")
>      > importFrom("graphics", "abline", "axis", "box", "mtext", "par", "title",
>      > "text")
>      > importFrom("methods", "is")
> 
>      > 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().
> 
> 
> 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 ..
> 
> Martin
> 
>      >> [...]
>      >> 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
>      > https://adriandusa.eu
> 
>      > [[alternative HTML version deleted]]
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>