Russ Lenth may have picked a suboptimal example (we could search through the dependencies of emmeans for an example with more non-(base+recommended) recursive dependencies, but the general point definitely holds.
"(formally undefined) recommended-level-2 R packages" seems like a can of worms (I know what would be on my list, but I wonder how much it would overlap everyone else's) FWIW I don't know of a better solution than #1 from the original post. cheers Ben Bolker On Fri, May 25, 2018 at 3:13 AM, Martin Maechler <maech...@stat.math.ethz.ch> wrote: >>>>>> Lenth, Russell V >>>>>> on Thu, 24 May 2018 23:14:42 +0000 writes: > > > Package developers, I am trying to severely cut down on > > the number of dependencies of my package emmeans. It is > > now 48, which is quite a few (but that is down from over > > 100 in the preceding version, where I made the unwise > > choice of including a particularly greedy package in > > Imports). I hate to force users to install dozens of > > packages that they don't really need or want, but it seems > > very hard to avoid. > > > Case in point: emmeans provides additional methods for > > 'cld' and 'glht' from the multcomp package. Accordingly, I > > import their generics, and register my additional > > methods. But because I import the generics, I must list > > multcomp in Imports, and that results in the addition of > > 16 required packages, some of which I never use. More > > important, I believe that NONE of those 16 packages are > > required for the correct functioning of my courtesy > > methods. The only things I really need are the generics. > > There must be a mistake here -- I think in your perception: > > 'multcomp' does *not* have excessive dependencies (though I'd > say one too much): > >> tools::package_dependencies("multcomp") > $multcomp > [1] "stats" "graphics" "mvtnorm" "survival" "TH.data" "sandwich" > [7] "codetools" > >> tools::package_dependencies("multcomp", recursive=TRUE) > $multcomp > [1] "stats" "graphics" "mvtnorm" "survival" "TH.data" "sandwich" > [7] "codetools" "methods" "utils" "zoo" "Matrix" "splines" > [13] "MASS" "grDevices" "grid" "lattice" > >> > > Apart from "base + recommended" packages (which *everyone* has installed), > these are just 4 packages: > > mvtnorm > TH.data > sandwich > zoo > > where mvtnorm, sandwich, and zoo really are among the > (formally undefined) recommended-level-2 R packages... so I do > wonder if you really had needed to install. > > The 'TH.data' { TH <==> maintainer("multcomp") } package I > think should not be in the strict dependencies of 'multcomp' but > rather in its "Suggests".... something I'd say must be true for > all data packages: > The whole idea of data packages is that they should be needed > for interesting help page examples, vignettes, maybe even tests, > but not for package functionality. > > In sum: I'd strongly advise to not change from keeping multcomp > among your imports. > > Martin Maechler > ETH Zurich > > > On the flip side, emmeans defines some generics of its own > > that I invite other package developers to extend so that > > emmeans supports their models. If those packages import > > emmeans, there is an overhead of 48 dependencies; again, > > most of these are packages that are not needed at all for > > those packages' methods to work. I don't like being > > responsible for that. > > > I believe this is a very common problem, not just with my > > own packages. It's one thing to extend a base method like > > 'print'; but extending methods in contributed packages > > creates these dependency explosions. I have hundreds of > > packages installed on my system - a couple dozen I care > > about, another few dozen that seem fairly desirable, and a > > couple hundred that I don't even know what they're for, > > other than that things will break if I uninstall them. > > > I do know of a couple ways to reduce these dependencies in > > the case of my multcomp dependencies: > > > 1. I could simply export my S3 methods for cld and glht as > > functions, rather than registering them as S3 methods. > > Then I could move multcomp to Suggests. The downside is > > that it clutters the namespace for emmeans. > > > 2. I could define the generics for cld and glht in my own > > package, and export them; and move multcomp to Suggests. > > Again, it clutters the namespace, and creates warning > > messages about (if not real issues with) masking. > > > Probably (1) is better than (2), but is it better than > > what I do now? Is there something else that I (and > > probably a whole lot of other people) don't know? > > > I wish there were an ImportGenerics or an > > ImportWithoutDependencies or some such field possible in > > DESCRIPTION. > > > I appreciate any suggestions. Thanks > > > Russ > > > -- > > Russell V. Lenth - Professor Emeritus Department of > > Statistics and Actuarial Science The University of Iowa > > - Iowa City, IA 52242 USA Voice (319)335-0712 - > > FAX (319)335-3017 russell-le...@uiowa.edu - > > http://www.stat.uiowa.edu/~rlenth/ > > > ______________________________________________ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > > ______________________________________________ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel