Skip to content

Latest commit

 

History

History
159 lines (107 loc) · 6.17 KB

GUIDELINES.md

File metadata and controls

159 lines (107 loc) · 6.17 KB
Raw

Guidelines for bioconda recipes

Requirements of a good bioconda recipe

  • Follows the Filesystem Hierarchy Standard (FSH). This is most important for libraries and Java packages; for these cases use one of the recipes below as a guideline.

  • Has adequate tests (see "Testing" section below)

  • License allows redistribution and license is indicated in meta.yaml

  • Does not already exist in the main Anaconda channel or the r channel. Exceptions: Anaconda version is too old or some sort of patch is required that is not in the main Anaconda channel (TODO: examples of the latter?)

Examples

The following recipes serve as examples of good recipes that can be used as guides or templates when developing new recipes.

Python

Use conda skeleton pypi <packagename> where packagename is a package available on PyPI. Either run that command in the recipes dir or move the recipe it creates to recipes. Typically can be used without modification, though dependencies may also need recipes.

If the recipe was created using conda skeleton pypi, then the default test is probably sufficient. The exception is when the package also installs a command-line tool, in which case that should be tested as well.

  • typical import check: pysam
  • import and command-line tests: chanjo

R (CRAN)

Use conda skeleton cran <packagename> where packagename is a package available on CRAN and is case-sensitive. Either run that command in the recipes dir or move the recipe it creates to recipes. The recipe name will have an r- prefix and will be converted to lowercase. Typically can be used without modification, though dependencies may also need recipes.

If the recipe was created using conda skeleton cran or the scripts/bioconductor_skeleton.py script, the default test is probably sufficient.

  • typical R recipe from CRAN: r-locfit
  • recipe for R package not on CRAN, also with patch: spp

R (Bioconductor)

Use scripts/bioconductor/bioconductor_skeleton.py <packagename> where packagename is a case-sensitive package available on Bioconductor. The recipe name will have a bioconductor- prefix and will be converted to lowercase. Typically can be used without modification, though dependencies may also need recipes. Recipes for dependencies with an r- prefix should be created using conda skeleton cran; see above.

Java

Add a wrapper script if the software is typically called via java -jar .... For example, fastqc already has a wrapper script, but gatk-framework does not. chromhmm mimics the installation pattern of gatk-framework.

JAR files should go in $PREFIX/share/$PKG_NAME-$PKG_VERSION-$PKG_BUILDNUM. A wrapper script should be placed here as well, and symlinked to $PREFIX/bin.

Example: gatk-framework Example with patch to fix memory: fastqc

Perl

Use conda skeleton cpan <packagename> to build a recipe for Perl and place the recipe in the recipes dir. The recipe will have the perl- prefix.

An example of such a package is perl-module-build.

Alternatively, ensure the build requirements for the recipe include perl-app-cpanminus, and the build.sh script can be simplified. An example of this is perl-time-hires.

If the recipe was created with conda skeleton cpan, the tests are likely sufficient. Otherwise, test the import of modules (see the imports section of the meta.yaml files in above examples).

C/C++

In general, standard make should work. Other build tools (e.g., autoconf) and compilers (e.g., gcc) should be specified in the build requirements.

General command-line tools

If a command-line tool is installed, it should be tested. If it has a shebang line, it should be patched to use /usr/bin/env for more general use.

An example of this is fastq-screen.

For command-line tools, running the program with no arguments, checking the programs version (e.g. with -v) or checking the command-line help is sufficient if doing so returns an exit code 0. Often the output is piped to /dev/null to avoid output during recipe builds.

Examples:

Other examples

Examples of somewhat non-standard recipes, in no particular order:

  • blast has an OS-specific installation -- OSX copies binaries while on Linux it is compiled.
  • graphviz has an OS-specific option to configure
  • crossmap removes libs that are shipped with the source distribution
  • hisat2 runs 2to3 to make it Python 3 compatible, and copies over individual scripts to the bin dir
  • htslib has a small test script that creates example data and runs multiple programs on it

Tests

An adequate test must be included in the recipe. An "adequate" test depends on the recipe, but must be able to detect a successful installation. While many packages may ship their own test suite (unit tests or otherwise), including these in the recipe is not recommended since it may timeout the build system on Travis-CI.

Note that a test must return an exit code of 0. The test can be in the test field of meta.yaml, or can be a separate script (see the relevant conda docs for testing).

It is recommended to pipe unneeded stdout/stderr to /dev/null to avoid cluttering the output in the Travis-CI build environment.

Versions

If an older version is required, put it in a subdirectory of the recipe. Examples of this can be found in bowtie2, bx-python, and others.