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.popave...@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.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 > -- Gabriel Becker, PhD Associate Scientist (Bioinformatics) Genentech Research [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
