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.adr...@unibuc.ro>
on Tue, 13 Mar 2018 09:17:08 +0200 writes:
> On Mon, Mar 12, 2018 at 2:18 PM, Martin Maechler
<maech...@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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
