Thanks all, I don't know either (for the moment). It's all in the design phase still. Generally, I would also like to keep specific functions in specific packages, if at all possible. On Fri, Apr 8, 2016 at 3:03 PM, Mark van der Loo <mark.vanderloo at gmail.com> wrote:> Well, I'm not saying that Dmitri _should_ do it. I merely mention it as an > option that I think is worth thinking about -- it is easy to overlook the > obvious :-). Since we have no further info on the package's structure we > can't be sure.. > > > > > Op vr 8 apr. 2016 om 13:59 schreef Adrian Du?a <dusa.adrian at unibuc.ro>: > >> 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]]
Another, perhaps slightly off the wall reframing of the 3-package possibility: Have packages B, a, and UserFacingA, as follows *a* contains all the functionality in your A package that *does not depend on B* *B* *imports from* *a* and is essentially unchanged *UserFacingA* *Depends* on *a* and *imports from* *B*, it implements all functionality from your package A that *does depend on* *B*, and gets the rest from package *a* Users, then would only ever install or load B and UserFacingA. They wouldn't need to care much,if at all, about package a. ~G On Fri, Apr 8, 2016 at 7:36 AM, Dmitri Popavenko <dmitri.popavenko at gmail.com> wrote:> Thanks all, I don't know either (for the moment). > It's all in the design phase still. Generally, I would also like to keep > specific functions in specific packages, if at all possible. > > On Fri, Apr 8, 2016 at 3:03 PM, Mark van der Loo <mark.vanderloo at gmail.com > > > wrote: > > > Well, I'm not saying that Dmitri _should_ do it. I merely mention it as > an > > option that I think is worth thinking about -- it is easy to overlook the > > obvious :-). Since we have no further info on the package's structure we > > can't be sure.. > > > > > > > > > > Op vr 8 apr. 2016 om 13:59 schreef Adrian Du?a <dusa.adrian at unibuc.ro>: > > > >> 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]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >-- Gabriel Becker, PhD Associate Scientist (Bioinformatics) Genentech Research [[alternative HTML version deleted]]
A third possibility, which I use in my gtools and gdata packages, is to use soft-links to create a copy of the relevant functions from one package in the other. I make sure these functions are *not* exported, so no conflicts are created, and the use of soft-links mean the code never gets out of sync. -Greg -- Change your thoughts and you change the world. --Dr. Norman Vincent Peale> On Apr 8, 2016, at 11:37 AM, Gabriel Becker <gmbecker at ucdavis.edu> wrote: > > Another, perhaps slightly off the wall reframing of the 3-package > possibility: > > Have packages B, a, and UserFacingA, as follows > > *a* contains all the functionality in your A package that > *does not depend on B* > *B* *imports from* *a* and is essentially unchanged > *UserFacingA* *Depends* on *a* and *imports from* *B*, it implements all > functionality from your package A that *does depend on* *B*, and gets the > rest from package *a* > > Users, then would only ever install or load B and UserFacingA. They > wouldn't need to care much,if at all, about package a. > > ~G > > On Fri, Apr 8, 2016 at 7:36 AM, Dmitri Popavenko <dmitri.popavenko at gmail.com >> wrote: > >> Thanks all, I don't know either (for the moment). >> It's all in the design phase still. Generally, I would also like to keep >> specific functions in specific packages, if at all possible. >> >> On Fri, Apr 8, 2016 at 3:03 PM, Mark van der Loo <mark.vanderloo at gmail.com >> wrote: >> >>> Well, I'm not saying that Dmitri _should_ do it. I merely mention it as >> an >>> option that I think is worth thinking about -- it is easy to overlook the >>> obvious :-). Since we have no further info on the package's structure we >>> can't be sure.. >>> >>> >>> >>> >>> Op vr 8 apr. 2016 om 13:59 schreef Adrian Du?a <dusa.adrian at unibuc.ro>: >>> >>>> 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]] >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > > > -- > Gabriel Becker, PhD > Associate Scientist (Bioinformatics) > Genentech Research > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel[[alternative HTML version deleted]]