Bioconda lets you install thousands of software packages related to biomedical research using the conda package manager.
NOTE: Bioconda supports only 64-bit Linux and macOS
First, install conda. Then perform a one-time set up of Bioconda with the following commands:
conda config --add channels defaults conda config --add channels bioconda conda config --add channels conda-forge conda config --set channel_priority strict
What did these commands do?
In general, running
conda config modifies your condarc file which can be
~/.condarc by default.
The first three commands add channels, from lowest to highest priority. The order is important to avoid problems with solving dependencies:
conda config --add channels defaults conda config --add channels bioconda conda config --add channels conda-forge
defaultschannel is the one set by default in a new installation of conda. It should be set to the lowest priority.
biocondachannel enables installation of packages related to biomedical research.
conda-forgechannel (see docs) enables installation of general-purpose packages. Since
biocondaheavily depends on the
conda-forgechannel, it is set to highest priority.
conda config --set channel_priority strict
avoids cryptic errors when tryng to install. It ensures that the channel priority configured above is respected when solving dependencies. See this section of the conda-forge docs for more info.
What if I don't want to modify my condarc?
Sometimes you might want to specify the channel priority directly in the
conda command-line call when installing a package or creating an
environment, and not edit the condarc file with the suggested
config commands above.
In that case, you would need to add the following arguments to
--channel conda-forge --channel bioconda --strict-channel-priority
For example, if you were creating an environment with bwa and samtools in it, you would use:
- conda create -n myenv samtools bwa
–channel conda-forge –channel bioconda –channel defaults –strict-channel-priority
Note that conda interprets channels on the command line in order
of decreasing priority (in contrast to
conda config, where they are
listed in increasing priority).
Now you can use
conda to install and use any of the packages available in
How do I speed up package installation?
Sometimes conda can spend a lot of time trying to solve dependencies for an environment. See How do I speed up package installation? in the FAQs for some options to improve this.
How do I get Docker containers of packages?
Every conda package in Bioconda has a corresponding Docker BioContainer automatically created and uploaded to Quay.io. A list of these and other containers can be found at the BioContainers Registry. For example:
docker pull quay.io/biocontainers/samtools:1.15.1--h1170115_0
If you have docker installed, you do not need any additional configuration.
The Bioconda channel is the primary output for users, but it takes a team of contributors and additional infrastructure to make it all happen. The entire system consists of the components illustrated in the diagram below.
Legend (starting from the bottom):
① Over 1400 contributors who add, modify, update, and maintain recipes and packages
Contributors to Bioconda add new recipes or update existing recipes by opening pull requests to GitHub. Contributors might include:
authors of the software
Bioconda core team
anyone interested creating a conda package
There’s even a Bioconda bot that watches common places for updates (like CRAN, PyPI, GitHub releases) and submits a pull request with the update for other contributors to review.
② A repository of recipes hosted on GitHub
The full history of all recipes is stored in the repository of recipes on GitHub.
Contributors and Bioconda core team coordinate, collaborate, and help each other out via comments on GitHub in issues and pull requests which are tested (see ③). The goal is to get a working package that satisfies the Bioconda policies.
③ A build system that turns each recipes into a conda package and a Docker container
Every time changes are pushed to a GitHub pull request (e.g., new recipe or updates to recipe), all of these changes are automatically built and tested. The results are reported back to the GitHub pull request page. Contributors work together to fix any issues (which are tested again) and the process repeats until all tests pass.
Our build system,
bioconda-utils, orchestrates the various building
and testing steps on Azure Pipelines. The output consists of both a conda
package and a Biocontainer that can be inspected before merging the
④ A repository of packages and a registry of containers containing over 8000 bioinformatics packages
When all tests pass and the pull request is merged into the main branch, two things happen:
⑤ Users can then use the package with
conda install or
See above for how to configure the conda channels. Using docker containers just needs docker installed.
The following plots show the recent usage of Bioconda in terms of number of downloads.
You can browse all packages in the Bioconda channel.
The Bioconda channel could not exist without support from:
Anaconda, Inc in the form of providing unlimited (in time and space) storage for packages in the channel.
Circle CI via an open source plan including free Linux and MacOS builds.
Amazon Web Services in the form of storage for BioContainers as well as compute credits.
Azure DevOps open source plan
GitHub Actions open source plan
The Bioconda logo is a derivative mark of Anaconda ®, a trademark of Anaconda, Inc registered in the U.S. and other countries. Anaconda, Inc. grants permission of the derivative use but is not associated with Bioconda.
When using Bioconda please cite our article:
Grüning, Björn, Ryan Dale, Andreas Sjödin, Brad A. Chapman, Jillian Rowe, Christopher H. Tomkins-Tinch, Renan Valieris, the Bioconda Team, and Johannes Köster. 2018. Bioconda: Sustainable and Comprehensive Software Distribution for the Life Sciences. Nature Methods, 2018 doi:10.1038/s41592-018-0046-7.
Former core members¶
Bioconda would not exist without the continuous hard work and support of the wonderful community which includes over 1400 (as of 2022) contributors.
Table of contents¶
- How do I speed up package installation?
- What versions are supported?
- How do I keep track of environments?
- What’s the difference between Anaconda, conda, Miniconda, and mamba?
- What’s the difference between a recipe and a package?
- What’s the difference between miniconda, miniforge, mambaforge, micromamba?
- Why are Bioconductor data packages failing to install?
- What’s the difference between a build number and a package version?
- Why shouldn’t I include build numbers in my environment YAMLs?
- Contributing to Bioconda
- Initial Setup
- Contribution Workflow
- Testing Recipes Locally
- Build system
- Guidelines for
- bioconda recipe checklist
- R (CRAN)
- R (Bioconductor)
- R (other sources)
- General command-line tools
- Other examples of interest
- Name collisions (identical names)
- Link and unlink scripts (pre- and post- install hooks)
- Skipping a lint check
- Lint Checks
- Incomplete Recipe
- Noarch or not noarch
- Recipe Parsing
- Build helpers
- Linter Errors
- Developer docs
- What’s the difference between Anaconda, conda, and Miniconda?
- Recipe vs package
- Continuous integration (Circle CI)
- How is Circle CI set up and configured?
- How are dependencies pinned to particular versions?
- What’s the lifecycle of a bioconda package?
- CircleCI macOS plans
- Where can I find more info on
- Updating recipes
- Updating recipes for a pinning change
- Conda build v3
- Developer Docs
- Bulk branch
- API docs
- GCB 2020 Tutorial
- What exactly is Conda?
- Conda packages
- Conda channels
- Finding Packages
- Practical 1
- Conda environments
- Conda environments
- Conda environments – common commands
- Practical 2
- Conda environments – common commands
- Common pitfalls
- Conda package recipes
- Don’t fear skeletons
- Practical 3
- Common problems
- Practical 4 and/or Q&A
- GCB 2020 Tutorial