[R-pkg-devel] More on explosive dependencies

[David Hugh-Jones]

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>
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
> 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 mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

	[[alternative HTML version deleted]]