Then, is there no way I can fix it?
Thank you.
Juhee Lee
2019년 10월 6일 (일) 오후 8:57, Duncan Murdoch 님이 작성:
> On 06/10/2019 3:07 a.m., Juhee Lee wrote:
> > I can see this result :
> >
> > * checking for file 'D:\Works\LAR\package\LARisk/DESCRIPTION' ... OK
> > * preparing 'LARisk':
> > * checkin
On 10.10.2019 15:41, Juhee Lee wrote:
Then, is there no way I can fix it?
Well we do not see any problems, so pls resubmit and the CRAN team will
tell you what problems are still apparent.
Best,
Uwe Ligges
Thank you.
Juhee Lee
2019년 10월 6일 (일) 오후 8:57, Duncan Murdoch 님이 작성:
On 06/1
Suppose package B imports package A and package A imports package C.
Shall package B import package C, knowing that package B will use functions
from package A that are using functions from package C ?
Currently, package B imports package C. This leads to a note from CRAN
stating
Namespace in I
Package B should import only the packages and functions that are used by
package B. If package B does not use functions from package C, package B should
not import package C. What package A does is package A's problem, not package
B's. If package A requires package C, install.packages() will au
I agree in general, but don't think that the situation is always so
straightforward.
A good example of the complexity is the case of reexported functions:
functions from other packages aimed at being used by users without the need
to load them from their original package.
For a concrete example, le
Seems quite clear to me. If dplyr chooses to re-implement pipes (e.g. based on
[1]) then you should not be importing from magrittr unless you had a specific
reason to, and if you do then you should not make assumptions about where the
dplyr pipe came from.
[1] https://github.com/moodymudskipper
