should we contribute to bioconda instead of maintaining this project on our own?

[gregcaporaso]

There is some discussion of this in #61 (ping @wasade, as he brought this up there). I think we should investigate ending this project in favor of contributing to bioconda. Thoughts on this?

@jairideout did a little research into bioconda and found that they're funded by continuum, and have a bunch of the same packages that we have here, including QIIME and vsearch.

[ElDeveloper]

:+1: this makes perfect sense!

Yoshiki Vázquez-Baeza

On Mar 2, 2016, at 12:31 PM, Greg Caporaso notifications@github.com wrote:

There is some discussion of this in #61 (ping @wasade, as he brought this up there). I think we should investigate ending this project in favor of contributing to bioconda. Thoughts on this?

@jairideout did a little research into bioconda and found that they're funded by continuum, and have a bunch of the same packages that we have here, including QIIME and vsearch.

— Reply to this email directly or view it on GitHub.

[wasade]

:+1:

On Wed, Mar 2, 2016 at 12:31 PM, Greg Caporaso notifications@github.com wrote:

There is some discussion of this in #61 https://github.com/biocore/conda-recipes/issues/61 (ping @wasade https://github.com/wasade, as he brought this up there). I think we should investigate ending this project in favor of contributing to bioconda. Thoughts on this?

@jairideout https://github.com/jairideout did a little research into bioconda and found that they're funded by continuum, and have a bunch of the same packages that we have here, including QIIME and vsearch.

— Reply to this email directly or view it on GitHub https://github.com/biocore/conda-recipes/issues/62.

[colinbrislawn]

Great question. We want to contribute to standard projects and avoid duplicate work.

Let's see how quickly these qiime PRs get excepted. If the bioconda devs are responsive, let's contribute over there.

[colinbrislawn]

These packages have been successfully added to Bioconda. (Not all offer cross platform support. Some are not up to date. Some do not have right version for qiime.)

• [x] ARAGORN
• [x] Diamond
• [x] FastTree
• [x] HMMER
• [x] Infernal
• [x] MAFFT
• [x] MinCED
• [x] Prodigal
• [x] SortMeRNA
• [x] VSEARCH
• [x] blastlegacy
• [x] blastplus
• [ ] micronota
• [x] rdp-tools
• [x] swarm

[sjanssen2]

I compared biocores recipes with what is available in bioconda and found the following:

These packages are in bioconda, sometimes with a newer version than available on biocore:

• Diamond (newer verison available)
• ARAGORN (same version)
• fasttree (same version)
• HMMER (same version)
• infernal (newer version available)
• mafft (newer version available)
• minced (same version)
• prodigal (newer version available)
• transtermhp (same version)
• vsearch (newer version available)
• blastplus (blast on bioconda is newer)
• rdp-tools (same version, but called "rdptools")
• swarm (newer version available)

Bioconda not yet has those recipes, we should think about migrating them to bioconda:

• blastlegacy (keep since we have better conda magic)
• sortmerna (keep since bioconda seems to use this one)
• disopred (missing in bioconda)
• memsat-svm (missing in bioconda)
• psipred (missing in bioconda)

I would say we should keep the following recipes in biocore since they are under our development and somehow in flux:

• biom-format (our version is newer)
• deblur (missing in bioconda)
• gneiss (missing in bioconda)
• micronota (missing in bioconda)
• q2-deblur (missing in bioconda)

In general, we have the issue that the basic libc on barnacle is somewhat outdated and pre-compiled binaries (like those installed via conda) might require a later version. We should be able to work around that issue by downloading the affected conda recipe from bioconda, compile i.e. conda build the package on barnacle, and upload the build to biocore.

What do you think about removing the above listed duplicated recipes in a first step? @gregcaporaso @ElDeveloper @wasade @RNAer @mortonjt @Jorge-C @colinbrislawn @ekopylova

[colinbrislawn]

What do you think about removing the above listed duplicated recipes in a first step?

I like this. I feel like our conda-recipes should be for our own software, or quirky dependencies that our software needs.

Edit: On the other hand, bioconda is massive. They have more than 2000 recipes, a packed built queue, and frequent updates to their build platform. Our little conda channel is easy to maintain.

[ElDeveloper]

I would suggest moving these recipes to conda-forge instead, that way we get automated builds and uploads to a public channel, plus admin access to the repos hosting the recipes. For example see this repo for Emperor: https://github.com/conda-forge/emperor-feedstock

In addition IIRC Anaconda Inc announced they were going to move to conda-forge instead of hosting the recipes themselves, so these can be maintained by the community.

On (Sep-28-17|22:37), Colin Brislawn wrote:

What do you think about removing the above listed duplicated recipes in a first step?

I like this. I feel like our conda-recipes should be for our own software, or quirky dependencies that our software needs.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/biocore/conda-recipes/issues/62#issuecomment-332982814

[sjanssen2]

@ElDeveloper are our tools within the cope of conda-forge? Shall we start by removing those recipes that are already bioconda? That might help solving the current build fails on the master branch.

[ElDeveloper]

Yes, any tool is within the scope of conda-forge, specially scientific software. I have find it very useful for pushing out conda builds (although note emperor has a very simple build process). That's a great idea regarding removing them when they are already part of bioconda, perhaps worth testing equivalency before removing.

On (Sep-29-17|16:01), Stefan Janssen wrote:

@ElDeveloper are our tools within the cope of conda-forge? Shall we start by removing those recipes that are already bioconda? That might help solving the current build fails on the master branch.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/biocore/conda-recipes/issues/62#issuecomment-333167321

[sjanssen2]

hm, how would you test equivalency if version numbers differ?

[ElDeveloper]

Running the unit tests of the software that depends on it, and perhaps checking by hand some of the output.

On (Sep-29-17|16:13), Stefan Janssen wrote:

hm, how would you test equivalency if version numbers differ?

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/biocore/conda-recipes/issues/62#issuecomment-333170231

[sjanssen2]

and you think that all those software packages comes with unit tests?! In principle, conda's meta.yaml allows for a test section, but in most recipes I saw so far, the only test is printing the help/usage message, i.e. not a real test.

[ElDeveloper]

hehehe, no no. I mean test in our own packages :) If one of our programs depends on say sortmerna, we should be able to run the unit tests of our program with the dependency as downloaded from bioconda.

On (Sep-29-17|16:18), Stefan Janssen wrote:

and you think that all those software packages comes with unit tests?! In principle, conda's meta.yaml allows for a test section, but in most recipes I saw so far, the only test is printing the help/usage message, i.e. not a real test.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/biocore/conda-recipes/issues/62#issuecomment-333171338