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