Order of DESCRIPTION Imports: and NAMESPACE import() in R 2.14.0 package checking

Tag: r , package , check Author: hazy0801 Date: 2011-10-21

I'm trying to chase down what seems to be a conflict between function names as I check a package. I may eventually ask directly about the problem, but first, I am wondering about three things, none of which seem to be mentioned in R-exts:

  1. The packages listed in DESCRIPTION: Imports and NAMESPACE imports() should be the same, right?
  2. Within either list, does the order of importing matter? If so, is there any general advice about how to order them?
  3. I use R --vanilla CMD check pkg_name to avoid having my .Rprofile interfere. When my .Rprofile is active and contains library(pkg_name) statements, does the order of those matter?

Best Answer

You asked three questions.

1. List packages in DESCRIPTION as well as NAMESPACE

Each package listed in DESCRIPTION Imports: must have a matching entry NAMESPACE import(...). The entry in DESCRIPTION may contain version information, but in NAMESPACE you only name the package.

Note for the unwary: Spell Imports with capital I and trailing s in DESCRIPTION

For example:

DESCRIPTION

Imports:
    stringr (>= 0.5)

NAMESPACE

import(stringr)

2. Order matters

Packages that you load or import later masks packages that were loaded or imported earlier. This only matters if you import packages that have export a function with identical name.

For example, both lattice and ggplot2 export a layer function. Thus if you first import lattice and then ggplot2, it means that ggplot2::layer will mask lattice::layer.

In other words, using layer will refer to ggplot2::layer. If you want to refer to the lattice version you need to explicitly refer to lattice::layer in your function.

3. The order of loading packages also matter

For the same reason, the order of loading packages (either in a script or in .Rprofile) matters. Any new package that you load will mask functions with the same name in previously loaded packages.

When this happens, R does the sensible thing and tells you about it in a console message.

Here is an example of masking that occurs when loading the reshape package, which depends on plyr but also masks some functions in plyr:

library(reshape)
Loading required package: plyr

Attaching package: 'plyr'

The following object(s) are masked from 'package:braidppt':

    .


Attaching package: 'reshape'

The following object(s) are masked from 'package:plyr':

    rename, round_any

comments:

Thank you Andrie... your answer was very clear, and confirmed what I thought was going on. Now I have to figure out the order things need to be in. Maybe it's too obvious, but a note about this in R-exts would probably be useful.
Looking around a bit more, I see >conflicts(detail = TRUE) can help me find the problem.
Note that if you have conflicts, you should probably use importsFrom to just import the selected functions from each package