[Rd] Restrict package to load-only access - prevent attempts to attach it

Abby Spurdle @purd|e@@ @end|ng |rom gm@||@com
Wed Jun 24 02:09:38 CEST 2020

You could go one step down, print a note or a warning.

Also, you could combine different approaches:
Check for an (additional) environment variable.
If set, print a note, if not set, generate a warning (or an error).

That would prevent someone accidently attaching your package, and
would discourage them from doing it.
But would also allow people to attach your package, if they really want to.

On Wed, Jun 24, 2020 at 8:21 AM Henrik Bengtsson
<henrik.bengtsson using gmail.com> 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.
> Thanks,
> Henrik
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

More information about the R-devel mailing list