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.court...@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.voe...@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@r-project.org mailing list >> > https://stat.ethz.ch/mailman/listinfo/r-package-devel >> > >> >> ______________________________________________ >> R-package-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> -- Sent from my phone. Please excuse my brevity. ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
