[Rd] (no) circular dependency

Gregory Warnes greg at warnes.net
Fri Apr 8 19:04:20 CEST 2016 

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

	[[alternative HTML version deleted]]

More information about the R-devel mailing list