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

[Jeff Newmiller]

As Duncan said, if you are calling FROM a function in your package, and the function you are CALLING is in the same package, then you do NOT need any colons at all, whether exported or not.

On September 14, 2020 7:30:12 AM PDT, "Wang, Zhu" <wangz1 using uthscsa.edu> wrote:
>In mypkg, I want to call a function foo from pkg,  and foo is not
>exported. I thought I should use pkg:: or pkg:::, but R CMD check
>provided a warning.
>
>Thanks,
>Zhu
>
>> 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.
>
>-----Original Message-----
>From: Duncan Murdoch <murdoch.duncan using gmail.com> 
>Sent: Monday, September 14, 2020 7:17 AM
>To: Wang, Zhu <wangz1 using uthscsa.edu>; 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 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
>> 
>
>______________________________________________
>R-package-devel using r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.