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.tri...@gmail.com> wrote: > 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 > > [[alternative HTML version deleted]] > > _______________________________________________ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
