adegenet
adegenet copied to clipboard
importing objects from readVCF (pegas) into genlight objects
@jgx65 @emmanuelparadis I am wondering if there is a risk of circular dependency here, or if the use of NAMESPACE now allows us to do that kind of stuff, i.e.
- package A imports from B the object xxx
- package B imports from A the object yyy
Which is actually not circulary in itself. I'll try later, but maybe you guys know already?
I think it's fine. If I remember correctly, the purpose of the NAMESPACE is, among other things, to create R environments with "copies" of (in fact, links towards) of the imported functions so that they are quickly accessed by the code of the package. So I don't think there an issue here.
I agree, but I'm thinking for installation purposes, like installing pegas which requires adegenet which requires pegas etc.
On Wed, Mar 25, 2015 at 9:34 AM, Emmanuel Paradis [email protected] wrote:
I think it's fine. If I remember correctly, the purpose of the NAMESPACE is, among other things, to create R environments with "copies" of (in fact, links towards) of the imported functions so that they are quickly accessed by the code of the package. So I don't think there an issue here.
— Reply to this email directly or view it on GitHub https://github.com/thibautjombart/adegenet/issues/20#issuecomment-86025720 .
I don't think it's a problem... unless the packages are new and not yet on CRAN... in which case you'll have to decide which one to submit first... a kind of "egg-chicken" dilemma :(
I see your point: the "egg-chicken" problem will appear when installing! Unless you force the install with install.packages(, dependencies = FALSE) for the 1st one to be installed.
Yep, my fear exactly.
On Wed, Mar 25, 2015 at 3:43 PM, Emmanuel Paradis [email protected] wrote:
I see your point: the "egg-chicken" problem will appear when installing! Unless you force the install with install.packages(, dependencies = FALSE) for the 1st one to be installed.
— Reply to this email directly or view it on GitHub https://github.com/thibautjombart/adegenet/issues/20#issuecomment-86088206 .
Here's a relevant thread: http://r.789695.n4.nabble.com/Submitting-packages-with-weak-circular-dependencies-to-CRAN-td4660766.html
On second thought, that issue I linked above says that A suggests B, whereas B imports A. In this situation, imports are coming from both sides. In my opinion, this is a Ripley magnet.
It definitely is ;) @emmanuelparadis the main question is, which way should dependencies go? Let's try a list of existing/potential deps:
adegenet's dependency on pegas
- HWE test: potential dep, not current one
- read.vcf: I actually don't need that if conversion functions to genind/genlight are implemented in pegas
pegas 's dependency on adegenet
- object classes
- read.xxx functions (to genind)
- is that it?
If so it looks like pegas should depend on adegenet, and not the other way around. Which means I can't build wrappers for functions in pegas. One solution I'd propose:
- deprecate HWE stuff in adegenet
- implement the same stuff in pegas, using the same name, outputting the same stuff, only using pegas internally That way, for users using pegas+adegenet together, there is no loss of functionality. What do you think?
Sounds good. So nothing to change on my side. I guess in your point 2) "ape" should be "adegenet"?
Sorry, no, point 2 is "pegas".
Sorry this is drifting from the original subject. Will repost in the HWE related issue