[R-pkg-devel] Use of `:::` in a package for code run in a parallel cluster

[Georgi Boshnakov]

You may have a case to argue to CRAN that you can get the "almost" exemption (can't say without details) but your views look overly rigid.

Exporting an object and marking it as internal is not a "work around", even less a "dirty trick". 
Export makes the object available outside the package's namespace and makes it clear that this is intentional. 
If you can't drop the 'package:::' prefix in your use case, this means that this is what you actually do (i.e. use those objects outside the namespace of the package). I would be grateful to CRAN for asking me to export and hence document this. 


Georgi Boshnakov

PS Note that there is no such thing as "public namespace".


-----Original Message-----
From: R-package-devel <r-package-devel-bounces using r-project.org> On Behalf Of David Kepplinger
Sent: 13 September 2020 20:52
To: R Package Devel <r-package-devel using r-project.org>
Subject: [R-pkg-devel] Use of `:::` in a package for code run in a parallel cluster

Dear list members,

I submitted an update for my package and got automatically rejected by the incoming checks (as expected from my own checks) for using `:::` calls to access the package's namespace.
"There are ::: calls to the package's namespace in its code. A package
*almost* never needs to use ::: for its own objects:…" (emphasis mine)

This was a conscious decision on my part as the package runs code on a user-supplied parallel cluster and I consider cluster-exporting the required functions a no-go as it would potentially overwrite objects in the clusters R sessions. The package code does not own the cluster and hence the R sessions. Therefore overwriting objects could potentially lead to unintended behaviour which is opaque to the user and difficult to debug.

Another solution to circumvent the R CMD check note is to export the functions to the public namespace but mark them as internal. This was also suggested in another thread on this mailing list (c.f. "Etiquette for package submissions that do not automatically pass checks?"). I do not agree with this work-around as the methods are indeed internal and should never be used by users. Exporting truly internal functions for the sake of satisfying R CMD check is a bad argument, in particular if there is a clean, well-documented, solution by using `:::`.

I argue `:::` is the only clean solution to this problem and no dirty work-arounds are necessary. This is a prime example of where `:::` is actually useful and needed inside a package. If the R community disagrees, I think R CMD check should at least emit a WARNING instead of a NOTE and elaborate on the problem and accepted work-arounds in "Writing R extensions". Or keep emitting a NOTE but listing those nebulous reasons where `:::` would be tolerated inside a package. Having more transparent criteria for submitting to CRAN would be really helpful to the entire R community and probably also reduce the traffic on this mailing list.

Best,
David

	[[alternative HTML version deleted]]

______________________________________________
R-package-devel using r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel