On Fri, Apr 8, 2016 at 10:34 PM, Hadley Wickham wrote:
> In that scenario, I would expect that QCA would suggest Venn and Venn
> would suggest QCA. Then there's no circular dependency problem.
>
Right, this is exactly what I was pointing myself in the first email:
- make package A dependent on
In that scenario, I would expect that QCA would suggest Venn and Venn
would suggest QCA. Then there's no circular dependency problem.
Hadley
On Fri, Apr 8, 2016 at 6:59 AM, Adrian Dușa wrote:
> Hi Mark,
>
> Uhm... sometimes this is not always possible.
> For example I have a package QCA which pr
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
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
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 *i
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
wrote:
> Well, I'm not saying that Dmitri _should_ do it. I mer
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 :
> Hi Ma
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 t
Hi all,
Oh right, I wasn't aware there is an r-package-devel list (probably better
suited for this question).
So I'm getting all sorts of advice, to create a big package and also better
to have multiple smaller ones. Sure, all of those are possible, just less
attractive. Adrian's suggestion might
> but this strategy quickly inflates the number of packages on CRAN.
CRAN contains 8210 packages today, so I would not worry about
adding an extra one.
Also, I think several small packages are preferable to one large one
because attaching a big one just to get the one or two functions you
want is
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
Hi Dmitri,
I was thinking about something similar for my packages. There might be
other (more clever) ways, but one way is to:
- make package A dependent on package B (so that the namespace of B is
automatically available when loading package A)
- make package B "Suggest" package A (not "Depend" w
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
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 w
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 f
15 matches
Mail list logo
