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