On 23/06/2020 4:21 p.m., Henrik Bengtsson wrote:
Hi,I'm developing a package whose API is only meant to be used in other packages via imports or pkg::foo(). There should be no need to attach this package so that its API appears on the search() path. As a maintainer, I want to avoid having it appear in search() conflicts by mistake. This means that, for instance, other packages should declare this package under 'Imports' or 'Suggests' but never under 'Depends'. I can document this and hope that's how it's going to be used. But, I'd like to make it explicit that this API should be used via imports or ::. One approach I've considered is: .onAttach <- function(libname, pkgname) { if (nzchar(Sys.getenv("R_CMD"))) return() stop("Package ", sQuote(pkgname), " must not be attached") } This would produce an error if the package is attached. It's conditioned on the environment variable 'R_CMD' set by R itself whenever 'R CMD ...' runs. This is done to avoid errors in 'R CMD INSTALL' and 'R CMD check' "load tests", which formally are *attach* tests. The above approach passes all the tests and checks I'm aware of and on all platforms. Before I ping the CRAN team explicitly, does anyone know whether this is a valid approach? Do you know if there are alternatives for asserting that a package is never attached. Maybe this is more philosophical where the package "contract" is such that all packages should be attachable and, if not, then it's not a valid R package. This is a non-critical topic but if it can be done it would be useful.
Speaking from the philosophical side, I think this is probably a bad idea. Presumably you have some idea of how your package will be used, but in my experience, really interesting things happen when such assumptions aren't met, and people use code in different ways.
So I'd prefer that you didn't try to prevent me from using your package in some weird way. It's fine if you document that it's intended to be used in some particular way, but why try to prevent me from using it differently? Just tell me to read the docs when problems arise because of my misuse and I ask you for help.
Duncan Murdoch ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
