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

[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] https://github.com/moodymudskipper/fastpipe

On October 10, 2019 9:09:08 AM PDT, Alexandre Courtiol <alexandre.courtiol using gmail.com> wrote:
>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, let's take the pipe (%>%): the pipe comes
>originally from {magrittr} but is reexported by many other packages
>(e.g.
>{dplyr}).
>So if your package relies on {dplyr} and reexport the pipe too, then
>one
>could argue that you simply need to import {dplyr} and not {magrittr}.
>I am not so sure I would agree with this (but my heart is not settled
>on
>the matter) for 2 reasons:
>- first, if you to reexport the pipe, your documentation would (I
>think)
>link to a documentation linking to a documentation...
>- second, you would not give credit to the {magrittr} developers (yes,
>in
>part the same people in that case, but that is not the point).
>Looking at what RSudio people chose to do in that precise example, it
>seems
>that packages directly refer to {magrittr}.
>I think that in the end it is a matter of weighing the pros and cons,
>and
>that may depend on the case.
>Re-exports may be a special case but giving credit to the right
>developers
>may be worth thinking about whatever the situation.
>++
>Alex
>
>
>
>
>On Thu, 10 Oct 2019 at 17:28, Cesko Voeten
><c.c.voeten using hum.leidenuniv.nl>
>wrote:
>
>> 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
>> automatically install it when package C is being installed, just as
>package
>> C is installed when package B is being installed.
>>
>> I submit the following thought experiment: suppose that, at a later
>point
>> in time, package A is re-written to not need package C. In this case,
>it
>> would be incorrect for package B to still needlessly import package
>C.
>>
>> Best,
>> Cesko
>>
>> Op 10-10-2019 om 17:14 schreef neonira Arinoem:
>> > 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 Imports field not imported from: ‘lubridate’
>> >    All declared Imports should be used.
>> >
>> > Doing so, I expect package B user not to worry about needed package
>B
>> > dependencies.
>> >
>> >   What is the best way to to manage package transitive
>dependencies, in
>> such
>> > a case ?
>> >
>> > Neonira.
>> >
>> >       [[alternative HTML version deleted]]
>> >
>> > ______________________________________________
>> > R-package-devel using r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> >
>>
>> ______________________________________________
>> R-package-devel using r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>

-- 
Sent from my phone. Please excuse my brevity.