On 15 September 2020 at 10:27, Cesko Voeten wrote:
| the language provides an obvious way to do this, why write a semantic kludge
As already said, Occam's Razor give the answer: keep it simple(r) and don't
write the kludge. Stick it all into a package, load the package on every node
and use
Henrik,
I completely agree with everything you wrote, but note that the issue at hand
is using `:::' in *the same* package, for example when a package needs to
access its own internal functions from an outside context, where running on a
cluster node set up by the package is one thing I can
Without having read all of the comments already made here, but my
understanding why ::: is not allowed is because you are reaching into
the internal API that the package owner does not guarantee will exist
in the next release. If you rely on the internal code of another CRAN
package in your CRAN
Yes, my view is certainly rigid and I agree that in the cases where the
function is actually used directly by the user, exporting it is the correct
step.
However, it seems some packages actually need to access internal functions
from an outside context, but the code that accesses the function is
On 14/09/2020 11:56 a.m., Wang, Zhu wrote:
Yes, mypkg is different from pkg, and I am the maintainer of mypkg, but not
pkg. Otherwise, things can be easier. Sorry for not clear enough.
Then you should not call foo, for the reasons I stated.
Alternatives are to contact the maintainer of pkg
Yes, mypkg is different from pkg, and I am the maintainer of mypkg, but not
pkg. Otherwise, things can be easier. Sorry for not clear enough.
Thanks to Duncan for a practical solution.
Best,
Zhu
-Original Message-
From: Duncan Murdoch
Sent: Monday, September 14, 2020 10:49 AM
To:
On 14/09/2020 10:30 a.m., Wang, Zhu 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.
I'm assuming that mypkg is not the same as pkg; Jeff Newmiller's answer
assumes the opposite.
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" wrote:
>In mypkg, I want to call a function foo from
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
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
You may have a case to argue to CRAN that you can get the "almost" exemption
(can't say without details) but your views look overly rigid.
Exporting an object and marking it as internal is not a "work around", even
less a "dirty trick".
Export makes the object available outside the package's
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
Thank you all for the discussion and suggestions.
so making a package function baz available makes all functions in the
> package available -- a function in the package already has access to other
> functions in the namespace, whether those functions are exported or not, so
> there is no need to
On Sun, Sep 13, 2020 at 3:19 PM Duncan Murdoch wrote:
>
> 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
> >
At least in the 'parallel' package
library(parallel)
cl = makePSOCKcluster(2)
and because of the nature of the R language, the entire namespace is exported,
analogous to
baz <- local({
foo <- function() 2
function(...) foo()
})
so making a package function baz available makes all
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
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
17 matches
Mail list logo
