[Rd] importing namespaces from base packages
jari.oksanen at oulu.fi
Tue Mar 13 13:36:53 CET 2018
It seems that they are defined in tools/R/check.R. For instance, line
## 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 <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 ..
> >> [...]
> >> 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
More information about the R-devel