[R-pkg-devel] Use of `:::` in a package for code run in a parallel cluster
w@ngz1 @end|ng |rom uth@c@@@edu
Mon Sep 14 16:30:12 CEST 2020
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.
> 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.
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.
> -----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
>> *almost* never needs to use ::: for its own objects:…" (emphasis
>> 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
> 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.
>> 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.
>> [[alternative HTML version deleted]]
>> R-package-devel using r-project.org mailing list
> R-package-devel using r-project.org mailing list
More information about the R-package-devel