Upcoming NAMESPACE, Depends, Imports changes for 2.14.0 (some definitions/use please)

Question

If you are a package author, you are hopefully well aware of upcoming changes in package structure when we move to 2.14 in about a week. One of the changes is that all pack

Answer 1

I recently worked on this for one of my packages. Here are my new Depends, Imports, and Suggests lines

Depends: R (>= 2.15.0)
Imports: nlme, mvtnorm, KFAS (>= 0.9.11), stats, utils, graphics
Suggests: Hmisc, maps, xtable, stringr

stats, utils and graphics are part of base R, but the user could detach them and then my package wouldn't work. If you use R from the command line, you might think 'why would anyone detach those?'. But if a user is using RStudio, say, I could see them going through and 'unclicking' all the packages. Strange thing to do, nonetheless, I don't want my package to stop working if they do that. Or they might redefine, say, the plot function (or some other function) , and then my package would fail.

My NAMESPACE then has the following lines

import(KFAS)
import(stats)
import(utils)
import(graphics)

I don't want to go through and keep track of which stats, utils and graphics functions I use, so I import their whole namespaces. For KFAS, I only need 2 functions, but the exported function names changed between versions so I import the whole namespace and then in my code test which version the user has.

For mvtnorm and nlme, I only use one function so I import just those. I could import the whole namespace, but try to only import what I really use.

importFrom(mvtnorm, rmvnorm)
importFrom(nlme, fdHess)

The vignettes where the Suggests packages appear have

require(package)

lines in them.

For the exported functions in my NAMESPACE, I'm a little torn. CRAN has become strict in not allowing ::: in your package code. That means that if I don't export a function, I am restricting creative re-use. On the other hand, I understand the need to only export functions that you intend to maintain with a stable arg list and output otherwise we break each other's packages by changing the function interface.