[Rd] R CMD check and missing imports from base packages
maechler at lynne.stat.math.ethz.ch
Thu Apr 30 09:44:41 CEST 2015
>>>>> Gábor Csárdi <csardi.gabor at gmail.com>
>>>>> on Wed, 29 Apr 2015 23:07:09 -0400 writes:
> On Wed, Apr 29, 2015 at 8:12 PM, Paul Gilbert <pgilbert902 at gmail.com> wrote:
>> As I recall, several packages mask the simulate generic in stats, if you
>> are looking for examples.
> FWIW, here is a list of base* functions masked** by CRAN packages:
> Look at the long table in the end. simulate indeed comes up 16 times. (But
> read ** below.)
> * This only includes functions in base packages that are attached by
> ** The CRAN function names were taken from the manual page aliases, so a
> couple of them are not really function names, and some of them are probably
> not masking anything, but defining an S3 generic. This was a lot simpler
> than going over the namespaces of all CRAN packages.
> It seems that several base functions are masked, by several packages. I
> would need to get a better CRAN function list, though.
Thank you Gabor.
As Martin Morgan observed, many of these will be methods, S3 and
S3 and there is often no conflict and no masking at all for all
these, so I am claiming that your "statistics" are quite a bit
biased, and probably most of the more common names are proper
There is another issue, I've wanted to raise,
exemplified by my Rmpfr package [interface to the MPFR C library
for high-accuracy floating point computations]:
As it defines "mpfr"-ified versions of standard R functions
many of which are *not* generic, it must mask them.
E.g, currently, the following "are masked" messages (when
attaching Rmpfr) are unavoidable
Attaching package: ‘Rmpfr’
The following objects are masked from ‘package:stats’:
dbinom, dnorm, dpois, pnorm
The following objects are masked from ‘package:base’:
(Currently, there are also 'cbind' and 'rbind' being masked in
order to work with mpfr-number matrices ... but that should in
principle be avoidable)
I think these "... are masked" messages are still appropriate: After all,
pnorm() will really be taken from Rmpfr instead of from stats,
and the user should know that she is trusting the author of
Rmpfr (me) to do the right thing, when she calls pnorm(), namely
to call the equivalent stats::pnorm() for standard numbers, and
to call the MPFR-library code for mpfr-numbers.
- - - - - - - - - - - - - - - - - - - - - - - -
Now the above may have almost nothing to do with the original
subject. If I have understood your main point correctly, you are
suggesting that 'R CMD check' should start putting out a NOTE
when package code calls a function from one of a set of
"standard packages" (*) and the package author failed to use an
importFrom(<standard pkg>, <function>)
in his/her NAMESPACE.
I agree that this would be useful.
Actually, I think we have something like this in place already...
but maybe not strictly enough (?)
(*) IIUC, you suggested to use
"standard packages" := packages which are attached by default
in R, apart from package 'base' because that does come
immediately after the imports anyway (and because you cannot
explicity import from base).
More information about the R-devel