[Rd] (no) circular dependency

[Gabriel Becker]

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]]