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

Question

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?

Answer 1

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