Skip to content

[Bioc-devel] requireNamespace() / loadNamespace() vs. Imports: / Depends: / Suggests:

2 messages · Tim Triche, Jr., Michael Lawrence

Original
Tim Triche, Jr.
# 
Today I stumbled across requireNamespace() as a suggested approach to
managing sprawling dependencies, particularly in packages that are meant to
be "core" building blocks in e.g. BioC.

http://r-pkgs.had.co.nz/namespace.html

My reading (which may be very, very far off) is that when a desirable piece
of code is "optional" in the sense of "the user can opt not to install
these other 90 packages" but "suggested" in the sense of "it is suggested
that the user bite the bullet anyways", a compromise is to Suggest:
installation and then fail at runtime with a message from
requireNamespace("suggestedPackage") if the suggestion is not heeded.  Is
this considered good practice?

Mulling it over, my initial reaction of "hey, that's cheating!" has given
way to "this is a clever way not to overburden users".  Am I reading the
underlying logic correctly?  I can think of numerous applications for this
approach in packages I have developed, not the least of which is patching
an ancient piece of code that performs a generalized Gamma deconvolution
and once required C++ (hence I ended up commenting out the dependency,
which broke most Windows users' installation of the entire package).

Thanks,

--t
Michael Lawrence
# 
Modularization is a useful tool for managing complexity. In this case,
you could implement modularity in a number of ways, two obvious ones
are splitting functionality into different packages and wrapping code
in a conditional call based on requireNamespace(). It is not always
obvious which approach to take for a given module. If it's
sufficiently complex, it probably belongs in its own package. One
advantage of requireNamespace() is that it advertises the
functionality while still controlling complexity. Like having a
separate package, it still requires the user to take an extra step,
but discovering the functionality may have been easier.

Michael
On Thu, Apr 27, 2017 at 10:01 AM, Tim Triche, Jr. <tim.triche at gmail.com> wrote: