[R-pkg-devel] no visible global function definition for ‘par’

Martin Maechler maechler at stat.math.ethz.ch
Tue Jan 31 09:17:47 CET 2017


>>>>> Dirk Eddelbuettel <edd at debian.org>
>>>>>     on Mon, 30 Jan 2017 20:50:19 -0600 writes:

    > On 30 January 2017 at 09:58, Kevin Ushey wrote:
    > | The correct thing to do is indeed import any functions from any R packages
    > | you use, base or otherwise. The simplest fix, if you don't want to
    > | selectively import such a large range of functions, is to simply add e.g.
    > | 
    > |     import(utils)
    > |     import(stats)
    > |     ... etc ...
    > | 
    > | to your NAMESPACE file.

    > Or do what R CMD check suggested and import the ones used, rather than all.

    > Which is what I had quoted earlier:

    > | Consider adding
    > | 
    > |   importFrom("grDevices", "as.raster", "dev.cur", "dev.off", "gray",
    > |              "heat.colors", "jpeg", "palette", "pdf", "png", "rainbow",
    > |              "terrain.colors", "tiff")
    > |   importFrom("graphics", "abline", "axis", "barplot", "box", "boxplot",
    > |              "image", "layout", "legend", "lines", "mtext", "par",
    > |              "plot", "plot.new", "points", "rasterImage", "strwidth",
    > |              "text", "title")
    > |   importFrom("stats", "TukeyHSD", "acf", "aov", "ccf", "coefficients",
    > |              "drop1", "end", "fft", "median", "model.tables",
    > |              "na.action", "na.omit", "pf", "ts", "var")
    > |   importFrom("utils", "read.table", "str", "tail", "write.table")
    > | 
    > | to your NAMESPACE file.

    > I find this preferable and quite appreciate that R CMD check provides it.
    > Dirk

yes, and that is not only Dirk :

It *is* highly preferable and recommended, also in *the*
reference manual ("Writing R Extensions", aka WRE) for reasons
of
  - efficiency,
  - modularity and "self-documentation"
  - much better control against accidental name clashes,

There are very few exceptions where importing a whole namespace
makes sense and the above base packages are typically never part
of these exceptions.

Martin Maechler
ETH Zurich and R Core



More information about the R-package-devel mailing list