Hi Thierry, Thanks for that, the trouble is functions are package specific so moving from one package to another could be a solution, but I would rather save that as a last resort. As mentioned, creating a package C with all the common functions could also be an option, but this strategy quickly inflates the number of packages on CRAN. If no other option is possible, that could be the way but I was still thinking about a more direct solution if possible. Best, Dmitri On Thu, Apr 7, 2016 at 3:47 PM, Thierry Onkelinx <thierry.onkelinx at inbo.be> wrote:> Dear Dmitri, > > If it's only a small number of functions then move them the relevant > functions for A to B so that B works without A. Then Import these functions > from B in A. Hence A depends on B but B is independent of A. > > It is requires to move a lot of functions than you better create a package > C with all the common functions. Then A and B import those functions from C. > > Best regards, > > ir. Thierry Onkelinx > Instituut voor natuur- en bosonderzoek / Research Institute for Nature and > Forest > team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance > Kliniekstraat 25 > 1070 Anderlecht > Belgium > > To call in the statistician after the experiment is done may be no more > than asking him to perform a post-mortem examination: he may be able to say > what the experiment died of. ~ Sir Ronald Aylmer Fisher > The plural of anecdote is not data. ~ Roger Brinner > The combination of some data and an aching desire for an answer does not > ensure that a reasonable answer can be extracted from a given body of data. > ~ John Tukey > > 2016-04-06 8:42 GMT+02:00 Dmitri Popavenko <dmitri.popavenko at gmail.com>: > >> Hello all, >> >> I would like to build two packages (say A and B), for two different >> purposes. >> Each of them need one or two functions from the other, which leads to the >> problem of circular dependency. >> >> Is there a way for package A to import a function from package B, and >> package B to import a function from package A, without arriving to >> circular >> dependency? >> Other suggestions in the archive mention building a third package that >> both >> A and B should depend on, but this seems less attractive. >> >> I read about importFrom() into the NAMESPACE file, but I don't know how to >> relate this with the information in the DESCRIPTION file (other than >> adding >> each package to the Depends: field). >> >> Thank you, >> Dmitri >> >> [[alternative HTML version deleted]] >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > >[[alternative HTML version deleted]]
Hi Dmitri,
I was thinking about something similar for my packages. There might be
other (more clever) ways, but one way is to:
- make package A dependent on package B (so that the namespace of B is
automatically available when loading package A)
- make package B "Suggest" package A (not "Depend" which
leads to circular
dependency), and that if I am not mistaken will lead to automatically
install package A when package B is installed
- use requireNamespace("A") inside the function(s) of package B which
uses
functions of package A
- directly use A::foo() inside those functions
Didn't try this yet, but in theory it should work (I might try this
approach myself actually). I would also be curious if there are more clever
ways to deal with this.
I hope it helps,
Adrian
On Thu, Apr 7, 2016 at 11:22 PM, Dmitri Popavenko <
dmitri.popavenko at gmail.com> wrote:
> Hi Thierry,
>
> Thanks for that, the trouble is functions are package specific so moving
> from one package to another could be a solution, but I would rather save
> that as a last resort.
>
> As mentioned, creating a package C with all the common functions could also
> be an option, but this strategy quickly inflates the number of packages on
> CRAN. If no other option is possible, that could be the way but I was still
> thinking about a more direct solution if possible.
>
> Best,
> Dmitri
>
> On Thu, Apr 7, 2016 at 3:47 PM, Thierry Onkelinx <thierry.onkelinx at
inbo.be
> >
> wrote:
>
> > Dear Dmitri,
> >
> > If it's only a small number of functions then move them the
relevant
> > functions for A to B so that B works without A. Then Import these
> functions
> > from B in A. Hence A depends on B but B is independent of A.
> >
> > It is requires to move a lot of functions than you better create a
> package
> > C with all the common functions. Then A and B import those functions
> from C.
> >
> > Best regards,
> >
> > ir. Thierry Onkelinx
> > Instituut voor natuur- en bosonderzoek / Research Institute for Nature
> and
> > Forest
> > team Biometrie & Kwaliteitszorg / team Biometrics & Quality
Assurance
> > Kliniekstraat 25
> > 1070 Anderlecht
> > Belgium
> >
> > To call in the statistician after the experiment is done may be no
more
> > than asking him to perform a post-mortem examination: he may be able
to
> say
> > what the experiment died of. ~ Sir Ronald Aylmer Fisher
> > The plural of anecdote is not data. ~ Roger Brinner
> > The combination of some data and an aching desire for an answer does
not
> > ensure that a reasonable answer can be extracted from a given body of
> data.
> > ~ John Tukey
> >
> > 2016-04-06 8:42 GMT+02:00 Dmitri Popavenko <dmitri.popavenko at
gmail.com>:
> >
> >> Hello all,
> >>
> >> I would like to build two packages (say A and B), for two
different
> >> purposes.
> >> Each of them need one or two functions from the other, which leads
to
> the
> >> problem of circular dependency.
> >>
> >> Is there a way for package A to import a function from package B,
and
> >> package B to import a function from package A, without arriving to
> >> circular
> >> dependency?
> >> Other suggestions in the archive mention building a third package
that
> >> both
> >> A and B should depend on, but this seems less attractive.
> >>
> >> I read about importFrom() into the NAMESPACE file, but I don't
know how
> to
> >> relate this with the information in the DESCRIPTION file (other
than
> >> adding
> >> each package to the Depends: field).
> >>
> >> Thank you,
> >> Dmitri
> >>
> >> [[alternative HTML version deleted]]
> >>
> >> ______________________________________________
> >> R-devel at r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >
> >
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Adrian Dusa
University of Bucharest
Romanian Social Data Archive
Soseaua Panduri nr.90
050663 Bucharest sector 5
Romania
[[alternative HTML version deleted]]
At the risk of stating the over-obvious: there's also the option of creating just a single package containing all functions. None of the functions that create the interdependencies need to be exported that way. Btw, his question is probably better at home at the r-package-devel list. Best, M On Thu, Apr 7, 2016, 22:24 Dmitri Popavenko <dmitri.popavenko at gmail.com> wrote:> Hi Thierry, > > Thanks for that, the trouble is functions are package specific so moving > from one package to another could be a solution, but I would rather save > that as a last resort. > > As mentioned, creating a package C with all the common functions could also > be an option, but this strategy quickly inflates the number of packages on > CRAN. If no other option is possible, that could be the way but I was still > thinking about a more direct solution if possible. > > Best, > Dmitri > > On Thu, Apr 7, 2016 at 3:47 PM, Thierry Onkelinx <thierry.onkelinx at inbo.be > > > wrote: > > > Dear Dmitri, > > > > If it's only a small number of functions then move them the relevant > > functions for A to B so that B works without A. Then Import these > functions > > from B in A. Hence A depends on B but B is independent of A. > > > > It is requires to move a lot of functions than you better create a > package > > C with all the common functions. Then A and B import those functions > from C. > > > > Best regards, > > > > ir. Thierry Onkelinx > > Instituut voor natuur- en bosonderzoek / Research Institute for Nature > and > > Forest > > team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance > > Kliniekstraat 25 > > 1070 Anderlecht > > Belgium > > > > To call in the statistician after the experiment is done may be no more > > than asking him to perform a post-mortem examination: he may be able to > say > > what the experiment died of. ~ Sir Ronald Aylmer Fisher > > The plural of anecdote is not data. ~ Roger Brinner > > The combination of some data and an aching desire for an answer does not > > ensure that a reasonable answer can be extracted from a given body of > data. > > ~ John Tukey > > > > 2016-04-06 8:42 GMT+02:00 Dmitri Popavenko <dmitri.popavenko at gmail.com>: > > > >> Hello all, > >> > >> I would like to build two packages (say A and B), for two different > >> purposes. > >> Each of them need one or two functions from the other, which leads to > the > >> problem of circular dependency. > >> > >> Is there a way for package A to import a function from package B, and > >> package B to import a function from package A, without arriving to > >> circular > >> dependency? > >> Other suggestions in the archive mention building a third package that > >> both > >> A and B should depend on, but this seems less attractive. > >> > >> I read about importFrom() into the NAMESPACE file, but I don't know how > to > >> relate this with the information in the DESCRIPTION file (other than > >> adding > >> each package to the Depends: field). > >> > >> Thank you, > >> Dmitri > >> > >> [[alternative HTML version deleted]] > >> > >> ______________________________________________ > >> R-devel at r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > >> > > > > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >[[alternative HTML version deleted]]
> but this strategy quickly inflates the number of packages on CRAN.CRAN contains 8210 packages today, so I would not worry about adding an extra one. Also, I think several small packages are preferable to one large one because attaching a big one just to get the one or two functions you want is also a waste. Bill Dunlap TIBCO Software wdunlap tibco.com On Thu, Apr 7, 2016 at 1:22 PM, Dmitri Popavenko <dmitri.popavenko at gmail.com> wrote:> Hi Thierry, > > Thanks for that, the trouble is functions are package specific so moving > from one package to another could be a solution, but I would rather save > that as a last resort. > > As mentioned, creating a package C with all the common functions could also > be an option, but this strategy quickly inflates the number of packages on > CRAN. If no other option is possible, that could be the way but I was still > thinking about a more direct solution if possible. > > Best, > Dmitri > > On Thu, Apr 7, 2016 at 3:47 PM, Thierry Onkelinx <thierry.onkelinx at inbo.be > > > wrote: > > > Dear Dmitri, > > > > If it's only a small number of functions then move them the relevant > > functions for A to B so that B works without A. Then Import these > functions > > from B in A. Hence A depends on B but B is independent of A. > > > > It is requires to move a lot of functions than you better create a > package > > C with all the common functions. Then A and B import those functions > from C. > > > > Best regards, > > > > ir. Thierry Onkelinx > > Instituut voor natuur- en bosonderzoek / Research Institute for Nature > and > > Forest > > team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance > > Kliniekstraat 25 > > 1070 Anderlecht > > Belgium > > > > To call in the statistician after the experiment is done may be no more > > than asking him to perform a post-mortem examination: he may be able to > say > > what the experiment died of. ~ Sir Ronald Aylmer Fisher > > The plural of anecdote is not data. ~ Roger Brinner > > The combination of some data and an aching desire for an answer does not > > ensure that a reasonable answer can be extracted from a given body of > data. > > ~ John Tukey > > > > 2016-04-06 8:42 GMT+02:00 Dmitri Popavenko <dmitri.popavenko at gmail.com>: > > > >> Hello all, > >> > >> I would like to build two packages (say A and B), for two different > >> purposes. > >> Each of them need one or two functions from the other, which leads to > the > >> problem of circular dependency. > >> > >> Is there a way for package A to import a function from package B, and > >> package B to import a function from package A, without arriving to > >> circular > >> dependency? > >> Other suggestions in the archive mention building a third package that > >> both > >> A and B should depend on, but this seems less attractive. > >> > >> I read about importFrom() into the NAMESPACE file, but I don't know how > to > >> relate this with the information in the DESCRIPTION file (other than > >> adding > >> each package to the Depends: field). > >> > >> Thank you, > >> Dmitri > >> > >> [[alternative HTML version deleted]] > >> > >> ______________________________________________ > >> R-devel at r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > >> > > > > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >[[alternative HTML version deleted]]
Hi all, Oh right, I wasn't aware there is an r-package-devel list (probably better suited for this question). So I'm getting all sorts of advice, to create a big package and also better to have multiple smaller ones. Sure, all of those are possible, just less attractive. Adrian's suggestion might work (thanks), will have to see. Best, Dmitri On Fri, Apr 8, 2016 at 12:17 AM, William Dunlap <wdunlap at tibco.com> wrote:> > but this strategy quickly inflates the number of packages on CRAN. > > CRAN contains 8210 packages today, so I would not worry about > adding an extra one. > > Also, I think several small packages are preferable to one large one > because attaching a big one just to get the one or two functions you > want is also a waste. > > > Bill Dunlap > TIBCO Software > wdunlap tibco.com > > On Thu, Apr 7, 2016 at 1:22 PM, Dmitri Popavenko < > dmitri.popavenko at gmail.com> wrote: > >> Hi Thierry, >> >> Thanks for that, the trouble is functions are package specific so moving >> from one package to another could be a solution, but I would rather save >> that as a last resort. >> >> As mentioned, creating a package C with all the common functions could >> also >> be an option, but this strategy quickly inflates the number of packages on >> CRAN. If no other option is possible, that could be the way but I was >> still >> thinking about a more direct solution if possible. >> >> Best, >> Dmitri >> >> On Thu, Apr 7, 2016 at 3:47 PM, Thierry Onkelinx < >> thierry.onkelinx at inbo.be> >> wrote: >> >> > Dear Dmitri, >> > >> > If it's only a small number of functions then move them the relevant >> > functions for A to B so that B works without A. Then Import these >> functions >> > from B in A. Hence A depends on B but B is independent of A. >> > >> > It is requires to move a lot of functions than you better create a >> package >> > C with all the common functions. Then A and B import those functions >> from C. >> > >> > Best regards, >> > >> > ir. Thierry Onkelinx >> > Instituut voor natuur- en bosonderzoek / Research Institute for Nature >> and >> > Forest >> > team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance >> > Kliniekstraat 25 >> > 1070 Anderlecht >> > Belgium >> > >> > To call in the statistician after the experiment is done may be no more >> > than asking him to perform a post-mortem examination: he may be able to >> say >> > what the experiment died of. ~ Sir Ronald Aylmer Fisher >> > The plural of anecdote is not data. ~ Roger Brinner >> > The combination of some data and an aching desire for an answer does not >> > ensure that a reasonable answer can be extracted from a given body of >> data. >> > ~ John Tukey >> > >> > 2016-04-06 8:42 GMT+02:00 Dmitri Popavenko <dmitri.popavenko at gmail.com >> >: >> > >> >> Hello all, >> >> >> >> I would like to build two packages (say A and B), for two different >> >> purposes. >> >> Each of them need one or two functions from the other, which leads to >> the >> >> problem of circular dependency. >> >> >> >> Is there a way for package A to import a function from package B, and >> >> package B to import a function from package A, without arriving to >> >> circular >> >> dependency? >> >> Other suggestions in the archive mention building a third package that >> >> both >> >> A and B should depend on, but this seems less attractive. >> >> >> >> I read about importFrom() into the NAMESPACE file, but I don't know >> how to >> >> relate this with the information in the DESCRIPTION file (other than >> >> adding >> >> each package to the Depends: field). >> >> >> >> Thank you, >> >> Dmitri >> >> >> >> [[alternative HTML version deleted]] >> >> >> >> ______________________________________________ >> >> R-devel at r-project.org mailing list >> >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> >> > >> > >> >> [[alternative HTML version deleted]] >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > >[[alternative HTML version deleted]]
Hi Mark, Uhm... sometimes this is not always possible. For example I have a package QCA which produces truth tables (all combinations of presence / absence of causal conditions), and it uses the venn package to draw a Venn diagram. It is debatable if one should assimilate the "venn" package into the QCA package (other people might want Venn diagrams but not necessarily the other QCA functions). On the other hand, the package venn would like to use the QCA package to demonstrate its abilities to plot Venn diagrams based on truth tables produced by the QCA package. Both have very different purposes, yet both use functions from each other. So I'm with Bill Dunlap here that several smaller packages are preferable to one larger one, but on the other hand I can't separate those functions into a third package: the truth table production is very specific to the QCA package, while plotting Venn diagrams is very specific to the venn package. I don't see how to separate those functions from their main packages and create a third one that each would depend on. This is just an example, there could be others as well, reason for which I am (still) looking for a solution to: - preserve the current functionalities in packages A and B (to follow Dmitri's original post) - be able to use functions from each other - yet avoid circular dependency I hope this explains it, Adrian On Thu, Apr 7, 2016 at 11:36 PM, Mark van der Loo <mark.vanderloo at gmail.com> wrote:> At the risk of stating the over-obvious: there's also the option of > creating just a single package containing all functions. None of the > functions that create the interdependencies need to be exported that way. > > Btw, his question is probably better at home at the r-package-devel list. > > > Best, > > M > > > > > On Thu, Apr 7, 2016, 22:24 Dmitri Popavenko <dmitri.popavenko at gmail.com> > wrote: > >> Hi Thierry, >> >> Thanks for that, the trouble is functions are package specific so moving >> from one package to another could be a solution, but I would rather save >> that as a last resort. >> >> As mentioned, creating a package C with all the common functions could >> also >> be an option, but this strategy quickly inflates the number of packages on >> CRAN. If no other option is possible, that could be the way but I was >> still >> thinking about a more direct solution if possible. >> >> Best, >> Dmitri >> >> On Thu, Apr 7, 2016 at 3:47 PM, Thierry Onkelinx < >> thierry.onkelinx at inbo.be> >> wrote: >> >> > Dear Dmitri, >> > >> > If it's only a small number of functions then move them the relevant >> > functions for A to B so that B works without A. Then Import these >> functions >> > from B in A. Hence A depends on B but B is independent of A. >> > >> > It is requires to move a lot of functions than you better create a >> package >> > C with all the common functions. Then A and B import those functions >> from C. >> > >> > Best regards, >> > >> > ir. Thierry Onkelinx >> > Instituut voor natuur- en bosonderzoek / Research Institute for Nature >> and >> > Forest >> > team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance >> > Kliniekstraat 25 >> > 1070 Anderlecht >> > Belgium >> > >> > To call in the statistician after the experiment is done may be no more >> > than asking him to perform a post-mortem examination: he may be able to >> say >> > what the experiment died of. ~ Sir Ronald Aylmer Fisher >> > The plural of anecdote is not data. ~ Roger Brinner >> > The combination of some data and an aching desire for an answer does not >> > ensure that a reasonable answer can be extracted from a given body of >> data. >> > ~ John Tukey >> > >> > 2016-04-06 8:42 GMT+02:00 Dmitri Popavenko <dmitri.popavenko at gmail.com >> >: >> > >> >> Hello all, >> >> >> >> I would like to build two packages (say A and B), for two different >> >> purposes. >> >> Each of them need one or two functions from the other, which leads to >> the >> >> problem of circular dependency. >> >> >> >> Is there a way for package A to import a function from package B, and >> >> package B to import a function from package A, without arriving to >> >> circular >> >> dependency? >> >> Other suggestions in the archive mention building a third package that >> >> both >> >> A and B should depend on, but this seems less attractive. >> >> >> >> I read about importFrom() into the NAMESPACE file, but I don't know >> how to >> >> relate this with the information in the DESCRIPTION file (other than >> >> adding >> >> each package to the Depends: field). >> >> >> >> Thank you, >> >> Dmitri >> >> >> >> [[alternative HTML version deleted]] >> >> >> >> ______________________________________________ >> >> R-devel at r-project.org mailing list >> >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> >> > >> > >> >> [[alternative HTML version deleted]] >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >-- Adrian Dusa University of Bucharest Romanian Social Data Archive Soseaua Panduri nr.90 050663 Bucharest sector 5 Romania [[alternative HTML version deleted]]