Re: [R-pkg-devel] Seeking for best way to manage package transitive dependencies

2019-10-10 Thread Jeff Newmiller
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]

Re: [R-pkg-devel] Seeking for best way to manage package transitive dependencies

2019-10-10 Thread Alexandre Courtiol
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,

Re: [R-pkg-devel] Seeking for best way to manage package transitive dependencies

2019-10-10 Thread Cesko Voeten
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

Re: [R-pkg-devel] consider running tools::compactPDF(gs_quality = "ebook")

2019-10-10 Thread Juhee Lee
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': > > *