R devel - Apr 2015 - R CMD check and missing imports from base packages

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:
https://github.com/gaborcsardi/rfunctions/blob/master/rfunctions.md
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
default.
** 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.

Gabor

[...]

> Paul Gilbert
>
	[[alternative HTML version deleted]]

>>>>> 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:
    > https://github.com/gaborcsardi/rfunctions/blob/master/rfunctions.md
    > 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
    > default.
    > ** 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
methods.

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?:

      pmax, pmin

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


Martin Maechler
ETH Zurich

On Thu, Apr 30, 2015 at 3:44 AM, Martin Maechler <
maechler at lynne.stat.math.ethz.ch> wrote:
[...]
>
> 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.
>
Yes, correct.

I agree that this would be useful.
> Actually, I think we have something like this in place already...
> but maybe not strictly enough (?)
>
It is in place for non-standard packages. But not for the standard ones.
This code
calls a function from all base packages that are loaded by default:
https://github.com/gaborcsardi/baseimports/blob/master/R/baseimports.R#L11
and it generates these checks on R-release and R-devel, both without NOTEs
or WARNINGs:
https://travis-ci.org/gaborcsardi/baseimports/jobs/60903983
https://travis-ci.org/gaborcsardi/baseimports/jobs/60903984

Gabor

>
> (*) 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).
>
>
> Martin Maechler
> ETH Zurich
>
	[[alternative HTML version deleted]]