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().> [...] > 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]]
>>>>> 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]]
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
>