In that scenario, I would expect that QCA would suggest Venn and Venn would suggest QCA. Then there's no circular dependency problem.
Hadley On Fri, Apr 8, 2016 at 6:59 AM, Adrian Dușa <dusa.adr...@unibuc.ro> wrote: > 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 -- http://hadley.nz ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
