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-boun...@r-project.org> On Behalf Of
David Kepplinger
Sent: 13 September 2020 20:52
To: R Package Devel <r-package-devel@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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
