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-le...@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@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@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel