On 13/09/2020 3:51 p.m., David Kepplinger wrote:
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 `:::`
Who is calling this function: package code or user code? I assume it's
a bit of a mix: your package writes a script that calls the function
when it runs in user space. (It would help if you gave an explicit
example of when you need to use this technique.)
If my assumption is correct, there are other simple workarounds besides
exporting the functions. Instead of putting
pkg:::foo(args)
into your script, put
pkg::callInternal("foo", args)
where pkg::callInternal is an exported function that can look up
unexported functions in the namespace.
You may argue that you prefer pkg:::foo for some reason: to which I'd
respond that you are being rude to the CRAN volunteers. I've offered
two options (one in the previous thread, a different one here), and
there was a third one in that thread offered by Ivan Krylov. Surely one
of these is good enough for your needs, and you shouldn't force CRAN to
handle you specially.
Duncan
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
