Re: [R-pkg-devel] Seeking for best way to manage package transitive dependencies
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
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
>
>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
Re: [R-pkg-devel] Seeking for best way to manage package transitive dependencies
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
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
>
--
Alexandre Courtiol
http://sites.google.com/site/alexandrecourtiol/home
*"Science is the belief in the ignorance of experts"*, R. Feynman
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Seeking for best way to manage package transitive dependencies
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
