(no) circular dependency

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

        [[alternative HTML version deleted]]

--
Adrian Dusa
University of Bucharest
Romanian Social Data Archive
Soseaua Panduri nr.90
050663 Bucharest sector 5
Romania