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.dun...@gmail.com>
Sent: Monday, September 14, 2020 7:17 AM
To: Wang, Zhu <wan...@uthscsa.edu>; David Kepplinger
<david.kepplin...@gmail.com>; R Package Devel <r-package-devel@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-boun...@r-project.org> On
> Behalf Of Duncan Murdoch
> Sent: Sunday, September 13, 2020 3:20 PM
> To: David Kepplinger <david.kepplin...@gmail.com>; R Package Devel
> <r-package-devel@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@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
>
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
