importing objects from readVCF (pegas) into genlight objects

[jgx65]

[thibautjombart]

@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?

[emmanuelparadis]

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.

[thibautjombart]

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 .

[emmanuelparadis]

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 :(

[emmanuelparadis]

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.

[thibautjombart]

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 .

[zkamvar]

Here's a relevant thread: http://r.789695.n4.nabble.com/Submitting-packages-with-weak-circular-dependencies-to-CRAN-td4660766.html

[zkamvar]

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.

[thibautjombart]

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:

1. deprecate HWE stuff in adegenet
2. 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?

[emmanuelparadis]

Sounds good. So nothing to change on my side. I guess in your point 2) "ape" should be "adegenet"?

[thibautjombart]

Sorry, no, point 2 is "pegas".

[thibautjombart]

Sorry this is drifting from the original subject. Will repost in the HWE related issue