[Rd] (no) circular dependency

Fri Apr 8 21:25:09 CEST 2016

Hi Greg,

That's interesting but I assume those are self-contained functions.
In my case, the truthTable() function from package QCA depends on numerous
other functions in the QCA package so I'm not sure how feasible it is to
copy everything from each package to every other package.

Best,
Adrian

On Fri, Apr 8, 2016 at 8:04 PM, Gregory Warnes <greg at warnes.net> wrote:

> 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 <gmbecker at 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.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]]
>
> ______________________________________________
> 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]]