An import dependency in the implementation model is a stereotyped dependency whose source is an implementation subsystem and whose target is an implementation subsystem. The import dependency allows the public contents of the target subsystem to be referenced in the source subsystem.
"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:
A
using a "Depends"
directive.A
and ask them to do a more careful job of constructing their namespace (in the words of Martin Morgan in this related answer).Hadley Wickham gives an easy explanation (http://r-pkgs.had.co.nz/namespace.html):
Listing a package in either
Depends
orImports
ensures that it’s installed when needed. The main difference is that whereImports
just loads the package,Depends
attaches it. There are no other differences. [...]Unless there is a good reason otherwise, you should always list packages in
Imports
notDepends
. That’s because a good package is self-contained, and minimises changes to the global environment (including the search path). The only exception is if your package is designed to be used in conjunction with another package. For example, the analogue package builds on top of vegan. It’s not useful without vegan, so it has vegan inDepends
instead ofImports
. Similarly, ggplot2 should really Depend on scales, rather than Importing it.
Chambers in SfDA says to use 'Imports' when this package uses a 'namespace' mechanism and since all packages are now required to have them, then the answer might now be always use 'Imports'. In the past packages could have been loaded without actually having namespaces and in that case you would need to have used Depends.
Here is a simple question to help you decide which to use:
Does your package require the end user to have direct access to the functions of another package?
The only time you should use 'Depends' is when your package is an add-on or companion to another package, where your end user will be using functions from both your package and the 'Depends' package in their code. If your end user will only be interfacing with your functions, and the other package will only be doing work behind the scenes, then use 'Imports' instead.
The caveat to this is that if you add a package to 'Imports', as you usually should, your code will need to refer to functions from that package, using the full namespace syntax, e.g. dplyr::mutate()
, instead of just mutate()
. It makes the code a little clunkier to read, but it’s a small price to pay for better package hygiene.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With