[R-pkg-devel] Courtesy methods and explosive dependencies

[Ben Bolker]

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
<maechler using 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-lenth using uiowa.edu  -
>     >  http://www.stat.uiowa.edu/~rlenth/
>
>     > ______________________________________________
>     > R-package-devel using r-project.org mailing list
>     > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel