Better Explanation of When to Use Imports/Depends

Better explanation of when to use Imports/Depends

"Imports" is safer than "Depends" (and also makes a package using it a 'better citizen' with respect to other packages that do use "Depends").

A "Depends" directive attempts to ensure that a function from another package is available by attaching the other package to the main search path (i.e. the list of environments returned by search()). This strategy can, however, be thwarted if another package, loaded later, places an identically named function earlier on the search path. Chambers (in SoDA) uses the example of the function "gam", which is found in both the gam and mgcv packages. If two other packages were loaded, one of them depending on gam and one depending on mgcv, the function found by calls to gam() would depend on the order in which they those two packages were attached. Not good.

An "Imports" directive should be used for any supporting package whose functions are to be placed in <imports:packageName> (searched immediately after <namespace:packageName>), instead of on the regular search path. If either one of the packages in the example above used the "Imports" mechanism (which also requires import or importFrom directives in the NAMESPACE file), matters would be improved in two ways. (1) The package would itself gain control over which mgcv function is used. (2) By keeping the main search path clear of the imported objects, it would not even potentially break the other package's dependency on the other mgcv function.

This is why using namespaces is such a good practice, why it is now enforced by CRAN, and (in particular) why using "Imports" is safer than using "Depends".

---

Edited to add an important caveat:

There is one unfortunately common exception to the advice above: if your package relies on a package A which itself "Depends" on another package B, your package will likely need to attach A with a "Depends directive.

This is because the functions in package A were written with the expectation that package B and its functions would be attached to the search() path.

A "Depends" directive will load and attach package A, at which point package A's own "Depends" directive will, in a chain reaction, cause package B to be loaded and attached as well. Functions in package A will then be able to find the functions in package B on which they rely.

An "Imports" directive will load but not attach package A and will neither load nor attach package B. ("Imports", after all, expects that package writers are using the namespace mechanism, and that package A will be using "Imports" to point to any functions in B that it need access to.) Calls by your functions to any functions in package A which rely on functions in package B will consequently fail.

The only two solutions are to either:

1. Have your package attach package A using a "Depends" directive.
2. Better in the long run, contact the maintainer of package A and ask them to do a more careful job of constructing their namespace (in the words of Martin Morgan in this related answer).

Imports and Depends

Couple of points, and I will admit that I also find this confusing at times. But I revisited it recently, and here is my take:

1. "Depends" is how we used to do things; it is closest to "just loading all three":when your third depends on the other two, all three will get loaded.

2. With Namespaces, we can also import. That brings in just the stated symbols, which can be data or functions. I use this sometimes; it will not load the other package that you import from but just make the stated symbols available. As such, it is "lighter" than Depends.

3. If you do Depends, there is no need for Imports.

4. That is correct: If you use declarations in in NAMESPACE to import symbols from another packages, that other package needs to be listed in Imports: in the DESCRIPTION file.

How to handle dependencies (`Depends:`) of imported packages (`Imports:`)

You could have a look at my blog : http://r2d2.quartzbio.com/posts/package-depends-dirty-hack-solution.html
Now i have a better and cleaner solution but not published yet.
Hope it helps.

For an R package, how to efficiently move a package from Depends to Imports

That is very straightforward. Change

Depends: pkgA, pkgB, pgC

to

Imports: pkgA, pkgB, pgC

and also add this to the NAMESPACE file:

import("pkgA")
import("pkgB")
import("pkgC")

which will globally import all exported symbols so you can continue as before.

You can also selectively import via

importFrom("pkgA", "func1", "func2", "func3")

and if you run R CMD check it will actually (very helpfully) tell you which functions need this. The second method is somewhat more precise but a little more work to set up.

And I don't think we have a tool to remove 'spurious imports'. Finding which imports may be unused may be something you have to check manually (but trying to remove one and seeing if it still builds + checks fine).

import NAMESPACE and DESCRIPTION question?

I would suggest reading the Namespaces chapter of Hadley's R Packages book. But in short, the answer is No.

Are imported functions in the NAMESPACE file attached to the R session when the main package is attached?

No, they are not. Imported functions are available for use in the package internals, but not attached to the user's search tree.

Another source for info is, of course, Writing R Extensions. They describe IMPORTS as:

The ‘Imports’ field lists packages whose namespaces are imported from (as specified in the NAMESPACE file) but which do not need to be attached.

---

As a demonstration, the current version of ggplot2, v 3.2.1, has import(scales) in its NAMESPACE file. In a fresh R session, we can load ggplot2 and observe that the scales package is not attached:

library(ggplot2)
percent(1)
# Error in percent(1) : could not find function "percent"
scales::percent(1)
# [1] "100%"

ggplot2 uses functions from scales internally, and can do so without using the package::function notation. This is what the import(scales) accomplishes. However, unlike with Depends, scales is not attached for the user.

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

I've written a little on this topic at https://github.com/hadley/devtools/wiki/Namespaces.

To answer your questions:

1. See Dirk's answer.
2. Use roxygen2
3. Now that every package has a namespace there is little reason to use Depends.
4. require should only be used to load suggested packages

R package: description, selective import and namespace

From ?install.packages the default behavior is that Depends: and Imports: packages are installed if not already installed. Check out sessionInfo() and you'll see your Imports: are loaded (resident in memory) but not attached (available on disk). If your importFrom statements cover the symbols used in your package code, then your code will work for others (if there were missing imports, you would be warned about undefined global variables).

---

Related Topics