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

[Duncan Murdoch]

On 13/09/2020 8:47 p.m., Wang, Zhu wrote:
> Apologize if I hijack this thread, but the use of ::: is something I was puzzled.
> 
> I tried Duncan's solution in my R package mypkg, something like:
> 
> pkg::callInternal("foo", args)
> 
> R CMD check mypkg
> 
> * checking dependencies in R code ... WARNING
> '::' or ':::' import not declared from: ‘pkg'
> 
> I probably missed something here.

You don't need either pkg:: or pkg::: if you are calling the function 
from within the package.  You may need one of those if the call is 
coming from a user script.

If you use pkg:: from mypkg, you need to declare that mypkg Imports pkg. 
  (This is a line in its DESCRIPTION file.)  I think that's what the 
WARNING is telling you.

Duncan Murdoch

> 
> Thanks,
> Zhu
> 
> -----Original Message-----
> From: R-package-devel <r-package-devel-bounces using r-project.org> On Behalf Of Duncan Murdoch
> Sent: Sunday, September 13, 2020 3:20 PM
> To: David Kepplinger <david.kepplinger using gmail.com>; R Package Devel <r-package-devel using r-project.org>
> Subject: Re: [R-pkg-devel] Use of `:::` in a package for code run in a parallel cluster
> 
> 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 using r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
> 
> ______________________________________________
> R-package-devel using r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
>