[R-pkg-devel] More on explosive dependencies

[Lenth, Russell V]

For the methods registered by the code I show, those do NOT go in the NAMESPACE file, and there are no roxygen2 @export tags for those methods.

Russ

On Jul 17, 2018, at 12:41 AM, David Hugh-Jones <davidhughjones using gmail.com<mailto:davidhughjones using gmail.com>> wrote:


Hi Russell,

That's v helpful and I am going to try it myself. Can I just ask what goes in your namespace file (and what roxygen tags you use) for the relevant methods?

David


On Tue, 17 Jul 2018 at 02:29, Lenth, Russell V <russell-lenth using uiowa.edu<mailto:russell-lenth using uiowa.edu>> wrote:
Thanks to all who responded. I am pleased to say that with your help, I have managed to work around this problem by dynamically registering the methods. My file zzz.R contains code to register various methods having generics in coda and multcomp. Those packages are in Suggests (not Imports) and my code is:

.onLoad = function(libname, pkgname) {
    if (requireNamespace("coda", quietly = TRUE)) {
        register_s3_method("coda", "as.mcmc", "emmGrid")
        register_s3_method("coda", "as.mcmc.list", "emmGrid")
    }
    if (requireNamespace("multcomp", quietly = TRUE)) {
        register_s3_method("multcomp", "glht", "emmlf")
        register_s3_method("multcomp", "glht", "emmGrid")
        register_s3_method("multcomp", "cld", "emmGrid")
        register_s3_method("multcomp", "modelparm", "emmwrap")
     }
}

The function register_s3_method was copied from hms:::register_s3_method.  That function sets up and calls base::registerS3method if the package in the first argument is already loaded, and sets a hook to do so if it is not (or if it is subsequently unloaded and reloaded).

My package now has the desired small number of dependencies, and passes checks even with Sys.setenv(`_R_S3_METHOD_LOOKUP_BASEENV_AFTER_GLOBALENV_` = TRUE), i.e., require all S3 methods to be registered.

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 (Dept. office)  -  FAX (319)335-3017

-----Original Message-----
From: Lenth, Russell V
Sent: Sunday, July 15, 2018 8:24 PM
To: r-package-devel using r-project.org<mailto:r-package-devel using r-project.org>
Subject: More on explosive dependencies

Package developers,

I posted a question a couple of months ago dealing with how to reduce the number of dependencies in a package. Part of the specific issue I face is that I have a `cld` S3 method for which the generic is in the multcomp package, but I don't want to import multcomp because it comes with a number of unneeded dependencies.

My solution at first appeared to be that I could just export my function `cld.emmGrid`; then if users have the multcomp package, this method is available. I also moved multcomp from Imports to Suggests, so that it is no longer a dependency. This fix works just fine for me. It passed the preliminary CRAN checks and it was accepted by CRAN. But then I was advised that the package fails the CRAN checks with Debian because those checks require S3 methods to actually be registered.

So what I tried next is what Duncan Murdoch suggested earlier in this thread -- to register the method conditionally using the following code in my NAMESPACE:

    if (requireNamespace("multcomp")) {
        importFrom(multcomp, cld)
        S3method(cld, emmGrid)
    }

This worked fine in my initial testing, both with multcomp installed and with multcomp absent.

However, now the package doesn't pass the checking procedure. The reason apparently is that every package mentioned in import() or importFrom() -- conditionally or not -- must be listed in Imports in the DESCRIPTION file. I could move multcomp back to Imports, but that defeats the whole purpose of getting rid of unneeded dependencies. It's a Catch-22.

Is there any recourse possible? Alas, I'm guessing there isn't, unless we can convince everybody to allow unregistered S3 methods on all platforms. This situation makes it really difficult for package developers to provide methods for other contributors' packages and still keep theirs lightweight. Almost all S3 generics are very simple functions, so being forced to load a dozen or so namespaces just to register a method is crazy. Plus, the more dependencies a package has, the less robust it is to other developers' updates.

I'm now wondering how much interest there is in developing a separate package just for generics, say, "S3generics". We could all collaborate to contribute our own generics to that one package, move them out of our own packages, and instead import just that package.

Russ

______________________________________________
R-package-devel using r-project.org<mailto:R-package-devel using r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

	[[alternative HTML version deleted]]