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.vander...@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.adr...@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.vander...@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.popave...@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.onkel...@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.popave...@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@r-project.org mailing list >>>> >> https://stat.ethz.ch/mailman/listinfo/r-devel >>>> >> >>>> > >>>> > >>>> >>>> [[alternative HTML version deleted]] >>>> >>>> ______________________________________________ >>>> R-devel@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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
