should we contribute to bioconda instead of maintaining this project on our own? #62
Comments
|
👍 this makes perfect sense! Yoshiki Vázquez-Baeza
|
|
👍 On Wed, Mar 2, 2016 at 12:31 PM, Greg Caporaso notifications@github.com
|
|
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. |
|
These packages have been successfully added to Bioconda.
|
|
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:
Bioconda not yet has those recipes, we should think about migrating them to bioconda:
I would say we should keep the following recipes in biocore since they are under our development and somehow in flux:
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? |
I like this. I feel like our conda-recipes should be for our own software, or quirky dependencies that our software needs. Edit: |
|
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.
<!--
On the other hand, bioconda is massive. They have more than [2000 recipes](https://github.com/bioconda/bioconda-recipes/tree/master/recipes/), [a packed built queue](https://travis-ci.org/bioconda/bioconda-recipes/builds), and frequent updates to their build platform. Our little conda channel is easy to maintain.
-->
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#62 (comment)
|
|
@ElDeveloper are our tools within the cope of conda-forge? |
|
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:
#62 (comment)
|
|
hm, how would you test equivalency if version numbers differ? |
|
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:
#62 (comment)
|
|
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. |
|
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:
#62 (comment)
|
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.
The text was updated successfully, but these errors were encountered: