mirror of
https://github.com/MillironX/nf-core_modules.git
synced 2024-12-22 11:08:17 +00:00
Harshil Patel
GitHub
commit
526ad8a457
2 changed files with 73 additions and 44 deletions
115
README.md
115
README.md
|
|
@ -11,6 +11,7 @@ A repository for hosting [Nextflow DSL2](https://www.nextflow.io/docs/latest/dsl
|
|||
|
||||
- [Using existing modules](#using-existing-modules)
|
||||
- [Adding a new module file](#adding-a-new-module-file)
|
||||
- [Guidelines](#guidelines)
|
||||
- [Testing](#testing)
|
||||
- [Documentation](#documentation)
|
||||
- [Uploading to `nf-core/modules`](#uploading-to-nf-coremodules)
|
||||
|
|
@ -22,7 +23,7 @@ A repository for hosting [Nextflow DSL2](https://www.nextflow.io/docs/latest/dsl
|
|||
|
||||
The module files hosted in this repository define a set of processes for software tools such as `fastqc`, `bwa`, `samtools` etc. This allows you to share and add common functionality across multiple pipelines in a modular fashion.
|
||||
|
||||
We have written a helper command in the `nf-core/tools` package that uses the GitHub API to obtain the relevant information for the module files present in the `software/` directory of this repository. This includes using `git` commit hashes to track changes for reproducibility purposes, and to download and install all of the relevant module files.
|
||||
We have written a helper command in the `nf-core/tools` package that uses the GitHub API to obtain the relevant information for the module files present in the [`software/`](software/) directory of this repository. This includes using `git` commit hashes to track changes for reproducibility purposes, and to download and install all of the relevant module files.
|
||||
|
||||
1. [Install](https://github.com/nf-core/tools#installation) the latest version of `nf-core/tools` (`>=1.10.2`)
|
||||
2. List the available modules:
|
||||
|
|
@ -104,16 +105,16 @@ but we are now gladly accepting submissions :)
|
|||
If you decide to upload a module to `nf-core/modules` then this will
|
||||
ensure that it will become available to all nf-core pipelines,
|
||||
and to everyone within the Nextflow community! See
|
||||
[`nf-core/modules/software`](https://github.com/nf-core/modules/tree/master/software)
|
||||
[`software/`](software)
|
||||
for examples.
|
||||
|
||||
### Current guidelines
|
||||
### Guidelines
|
||||
|
||||
The key words "MUST", "MUST NOT", "SHOULD", etc. are to be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).
|
||||
|
||||
#### General
|
||||
|
||||
* Software that can be piped together SHOULD be added to separate module files
|
||||
- Software that can be piped together SHOULD be added to separate module files
|
||||
unless there is a run-time, storage advantage in implementing in this way. For example,
|
||||
using a combination of `bwa` and `samtools` to output a BAM file instead of a SAM file:
|
||||
|
||||
|
|
@ -121,55 +122,97 @@ using a combination of `bwa` and `samtools` to output a BAM file instead of a SA
|
|||
bwa mem | samtools view -B -T ref.fasta
|
||||
```
|
||||
|
||||
* Where applicable, the usage/generation of compressed files SHOULD be enforced as input/output e.g. `*.fastq.gz` and NOT `*.fastq`, `*.bam` and NOT `*.sam` etc.
|
||||
* A module MUST NOT contain a `when` statement.
|
||||
* Where applicable, each module command MUST emit a file `<SOFTWARE>.version.txt` containing a single line with the software's version in the format `<VERSION_NUMBER>` or `0.7.17`:
|
||||
- Where applicable, the usage and generation of compressed files SHOULD be enforced as input and output, respectively:
|
||||
- `*.fastq.gz` and NOT `*.fastq`
|
||||
- `*.bam` and NOT `*.sam`
|
||||
|
||||
- Where applicable, each module command MUST emit a file `<SOFTWARE>.version.txt` containing a single line with the software's version in the format `<VERSION_NUMBER>` or `0.7.17` e.g.
|
||||
|
||||
```bash
|
||||
echo \$(bwa 2>&1) | sed 's/^.*Version: //; s/Contact:.*\$//' > ${software}.version.txt
|
||||
```
|
||||
|
||||
If the software is unable to output a version number on the command-line then a variable called `VERSION` can be manually specified to create this file e.g. [homer/annotatepeaks module](https://github.com/nf-core/modules/blob/master/software/homer/annotatepeaks/main.nf).
|
||||
If the software is unable to output a version number on the command-line then a variable called `VERSION` can be manually specified to create this file e.g. [homer/annotatepeaks module](https://github.com/nf-core/modules/blob/master/software/homer/annotatepeaks/main.nf).
|
||||
|
||||
- The process definition MUST NOT contain a `when` statement.
|
||||
|
||||
#### Naming conventions
|
||||
|
||||
* The directory structure for the module name must be all lowercase e.g. `software/bwa/mem/`. The name of the software (i.e. `bwa`) and tool (i.e. `mem`) MUST be all one word.
|
||||
* The process name in the module file MUST be all uppercase e.g. `process BWA_MEM {`. The name of the software (i.e. `BWA`) and tool (i.e. `MEM`) MUST be all one word separated by an underscore.
|
||||
* All parameter names MUST follow the `snake_case` convention.
|
||||
* All function names MUST follow the `camelCase` convention.
|
||||
- The directory structure for the module name must be all lowercase e.g. [`software/bwa/mem/`](software/bwa/mem/). The name of the software (i.e. `bwa`) and tool (i.e. `mem`) MUST be all one word.
|
||||
|
||||
- The process name in the module file MUST be all uppercase e.g. `process BWA_MEM {`. The name of the software (i.e. `BWA`) and tool (i.e. `MEM`) MUST be all one word separated by an underscore.
|
||||
|
||||
- All parameter names MUST follow the `snake_case` convention.
|
||||
|
||||
- All function names MUST follow the `camelCase` convention.
|
||||
|
||||
#### Module parameters
|
||||
|
||||
* A module file SHOULD only define input and output files as command-line parameters to be executed within the process.
|
||||
* All other parameters MUST be provided as a string i.e. `options.args` where `options` is a Groovy Map that MUST be provided in the `input` section of the process.
|
||||
* If the tool supports multi-threading then you MUST provide the appropriate parameter using the Nextflow `task` variable e.g. `--threads $task.cpus`.
|
||||
* Any parameters that need to be evaluated in the context of a particular sample e.g. single-end/paired-end data MUST also be defined within the process.
|
||||
- A module file SHOULD only define input and output files as command-line parameters to be executed within the process.
|
||||
|
||||
- All other parameters MUST be provided as a string i.e. `options.args` where `options` is a Groovy Map that MUST be provided in the `input` section of the process.
|
||||
|
||||
- If the tool supports multi-threading then you MUST provide the appropriate parameter using the Nextflow `task` variable e.g. `--threads $task.cpus`.
|
||||
|
||||
- Any parameters that need to be evaluated in the context of a particular sample e.g. single-end/paired-end data MUST also be defined within the process.
|
||||
|
||||
#### Input/output options
|
||||
|
||||
* Named file extensions MUST be emitted for ALL output channels e.g. `path "*.txt", emit: txt`.
|
||||
* Optional inputs are not currently supported by Nextflow. However, "fake files" MAY be used to work around this issue.
|
||||
- Named file extensions MUST be emitted for ALL output channels e.g. `path "*.txt", emit: txt`.
|
||||
|
||||
- Optional inputs are not currently supported by Nextflow. However, "fake files" MAY be used to work around this issue.
|
||||
|
||||
#### Resource requirements
|
||||
|
||||
* An appropriate resource `label` MUST be provided for the module as listed in the [nf-core pipeline template](https://github.com/nf-core/tools/blob/master/nf_core/pipeline-template/%7B%7Bcookiecutter.name_noslash%7D%7D/conf/base.config#L29) e.g. `process_low`, `process_medium` or `process_high`.
|
||||
* If the tool supports multi-threading then you MUST provide the appropriate parameter using the Nextflow `task` variable e.g. `--threads $task.cpus`.
|
||||
- An appropriate resource `label` MUST be provided for the module as listed in the [nf-core pipeline template](https://github.com/nf-core/tools/blob/master/nf_core/pipeline-template/%7B%7Bcookiecutter.name_noslash%7D%7D/conf/base.config#L29) e.g. `process_low`, `process_medium` or `process_high`.
|
||||
|
||||
- If the tool supports multi-threading then you MUST provide the appropriate parameter using the Nextflow `task` variable e.g. `--threads $task.cpus`.
|
||||
|
||||
#### Software requirements
|
||||
|
||||
[BioContainers](https://biocontainers.pro/#/) is a registry of Docker and Singularity containers automatically created from all of the software packages on [Bioconda](https://bioconda.github.io/). Where possible we will use BioContainers to fetch pre-built software containers and Bioconda to install software using Conda.
|
||||
|
||||
* Software requirements SHOULD be declared within the module file using the Nextflow `container` directive e.g. go to the [BWA BioContainers webpage](https://biocontainers.pro/#/tools/bwa), click on the `Pacakages and Containers` tab, sort by `Version` and get the portion of the link after the `docker pull` command where `Type` is Docker. You may need to double-check that you are using the latest version of the software because you may find that containers for older versions have been rebuilt more recently.
|
||||
- Software requirements SHOULD be declared within the module file using the Nextflow `container` directive e.g. go to the [BWA BioContainers webpage](https://biocontainers.pro/#/tools/bwa), click on the `Pacakages and Containers` tab, sort by `Version` and get the portion of the link after the `docker pull` command where `Type` is Docker. You may need to double-check that you are using the latest version of the software because you may find that containers for older versions have been rebuilt more recently.
|
||||
|
||||
* If the software is available on Conda the software should also be defined using the Nextflow `conda` directive. Software MUST be pinned to the channel (i.e. `bioconda`) and version (i.e. `0.7.17`) e.g. `bioconda::bwa=0.7.17`. Pinning the build too e.g. "bioconda::bwa=0.7.17=h9402c20_2" is not currently a requirement.
|
||||
- If the software is available on Conda it MUST also be defined using the Nextflow `conda` directive. Software MUST be pinned to the channel (i.e. `bioconda`) and version (i.e. `0.7.17`) e.g. `bioconda::bwa=0.7.17`. Pinning the build too is not currently a requirement e.g. `bioconda::bwa=0.7.17=h9402c20_2`.
|
||||
|
||||
* If required, multi-tool containers may also be available on BioContainers e.g. [`bwa` and `samtools`](https://biocontainers.pro/#/tools/mulled-v2-fe8faa35dbf6dc65a0f7f5d4ea12e31a79f73e40). It is also possible for a multi-tool container to be built and added to BioContainers by submitting a pull request on their [`multi-package-containers`](https://github.com/BioContainers/multi-package-containers) repository.
|
||||
- If required, multi-tool containers may also be available on BioContainers e.g. [`bwa` and `samtools`](https://biocontainers.pro/#/tools/mulled-v2-fe8faa35dbf6dc65a0f7f5d4ea12e31a79f73e40). It is also possible for a multi-tool container to be built and added to BioContainers by submitting a pull request on their [`multi-package-containers`](https://github.com/BioContainers/multi-package-containers) repository.
|
||||
|
||||
* If the software is not available on Bioconda a `Dockerfile` MUST be provided within the module directory. We will use GitHub Actions to auto-build the containers on the [GitHub Packages registry](https://github.com/features/packages).
|
||||
- If the software is not available on Bioconda a `Dockerfile` MUST be provided within the module directory. We will use GitHub Actions to auto-build the containers on the [GitHub Packages registry](https://github.com/features/packages).
|
||||
|
||||
#### Publishing results
|
||||
|
||||
The [Nextflow `publishDir`](https://www.nextflow.io/docs/latest/process.html#publishdir) definition is currently quite limited in terms of parameter/option evaluation. To overcome this, the publishing logic we have implemented for use with DSL2 modules attempts to minimise changing the `publishDir` directive (default: `params.outdir`) in favour of constructing and appending the appropriate output directory paths via the `saveAs:` statement e.g.
|
||||
|
||||
```nextflow
|
||||
publishDir "${params.outdir}",
|
||||
mode: params.publish_dir_mode,
|
||||
saveAs: { filename -> saveFiles(filename:filename, options:options, publish_dir:getSoftwareName(task.process), publish_id:meta.id) }
|
||||
```
|
||||
|
||||
The `saveFiles` function can be found in the [`functions.nf`](software/fastqc/functions.nf) file of utility functions that will be copied into all module directories. It uses the various publishing `options` specified as input to the module to construct and append the relevant output path to `params.outdir`.
|
||||
|
||||
We also use a standardised parameter called `params.publish_dir_mode` that can be used to alter the file publishing method (default: `copy`).
|
||||
|
||||
### Testing
|
||||
|
||||
- All test data for `nf-core/modules` MUST be added to [`tests/data/`](tests/data/) and organised by filename extension.
|
||||
|
||||
- Test files MUST be kept as tiny as possible.
|
||||
|
||||
- It is RECOMMENDED to re-use generic files from [`tests/data/`](tests/data/) by symlinking them into the [`test/`](software/fastqc/test) directory of the module.
|
||||
|
||||
- If the appropriate test data doesn't exist for your module then it MUST be added to [`tests/data`](tests/data/).
|
||||
|
||||
- Every module MUST be tested by adding a test workflow with a toy dataset in the [`test/`](software/fastqc/test) directory of the module.
|
||||
|
||||
### Documentation
|
||||
|
||||
- A module MUST be documented in the [`meta.yml`](software/fastqc/meta.yml) file. It MUST document `params`, `input` and `output`. `input` and `output` MUST be a nested list.
|
||||
|
||||
### Uploading to `nf-core/modules`
|
||||
|
||||
[Fork](https://help.github.com/articles/fork-a-repo/) the `nf-core/modules` repository to your own GitHub account. Within the local clone of your fork add the module file to the [`nf-core/modules/software`](https://github.com/nf-core/modules/tree/master/software) directory.
|
||||
[Fork](https://help.github.com/articles/fork-a-repo/) the `nf-core/modules` repository to your own GitHub account. Within the local clone of your fork add the module file to the [`software/`](software) directory.
|
||||
|
||||
Commit and push these changes to your local clone on GitHub, and then [create a pull request](https://help.github.com/articles/creating-a-pull-request-from-a-fork/) on the `nf-core/modules` GitHub repo with the appropriate information.
|
||||
|
||||
|
|
@ -179,8 +222,10 @@ We will be notified automatically when you have created your pull request, and p
|
|||
|
||||
The features offered by Nextflow DSL2 can be used in various ways depending on the granularity with which you would like to write pipelines. Please see the listing below for the hierarchy and associated terminology we have decided to use when referring to DSL2 components:
|
||||
|
||||
- *Module*: A `process` that can be used within different pipelines and is as atomic as possible i.e. cannot be split into another module. An example of this would be a module file containing the process definition for a single tool such as `FastQC`. At present, this repository has been created to only host atomic module files that should be added to the `software/` directory along with the required documentation and tests.
|
||||
- *Module*: A `process` that can be used within different pipelines and is as atomic as possible i.e. cannot be split into another module. An example of this would be a module file containing the process definition for a single tool such as `FastQC`. At present, this repository has been created to only host atomic module files that should be added to the [`software/`](software/) directory along with the required documentation and tests.
|
||||
|
||||
- *Sub-workflow*: A chain of multiple modules that offer a higher-level of functionality within the context of a pipeline. For example, a sub-workflow to run multiple QC tools with FastQ files as input. Sub-workflows should be shipped with the pipeline implementation and if required they should be shared amongst different pipelines directly from there. As it stands, this repository will not host sub-workflows although this may change in the future since well-written sub-workflows will be the most powerful aspect of DSL2.
|
||||
|
||||
- *Workflow*: What DSL1 users would consider an end-to-end pipeline. For example, from one or more inputs to a series of outputs. This can either be implemented using a large monolithic script as with DSL1, or by using a combination of DSL2 individual modules and sub-workflows.
|
||||
|
||||
## Help
|
||||
|
|
@ -201,28 +246,10 @@ If you use the module files in this repository for your analysis please you can
|
|||
|
||||
<!---
|
||||
|
||||
#### Publishing results
|
||||
|
||||
- The module MUST accept the parameters `params.out_dir` and `params.publish_dir` and MUST publish results into `${params.out_dir}/${params.publish_dir}`.
|
||||
- The `publishDirMode` MUST be configurable via `params.publish_dir_mode`
|
||||
- The module MUST accept a parameter `params.publish_results` accepting at least
|
||||
- `"none"`, to publish no files at all,
|
||||
- a glob pattern which is initalized to a sensible default value.
|
||||
|
||||
It MAY accept `"logs"` to publish relevant log files, or other flags, if applicable.
|
||||
|
||||
- To ensure consistent naming, files SHOULD be renamed according to the `$name` variable before returning them.
|
||||
|
||||
#### Testing
|
||||
|
||||
- Every module MUST be tested by adding a test workflow with a toy dataset.
|
||||
- Test data MUST be stored within this repo. It is RECOMMENDED to re-use generic files from `tests/data` by symlinking them into the test directory of the module. Specific files MUST be added to the test-directory directly. Test files MUST be kept as tiny as possible.
|
||||
|
||||
#### Documentation
|
||||
|
||||
- A module MUST be documented in the `meta.yml` file. It MUST document `params`, `input` and `output`. `input` and `output` MUST be a nested list. [Exact detail need to be elaborated. ]
|
||||
|
||||
|
||||
### Configuration and parameters
|
||||
|
||||
The module files hosted in this repository define a set of processes for software tools such as `fastqc`, `trimgalore`, `bwa` etc. This allows you to share and add common functionality across multiple pipelines in a modular fashion.
|
||||
|
|
|
|||
|
|
@ -34,6 +34,8 @@ process SOFTWARE_TOOL {
|
|||
saveAs: { filename -> saveFiles(filename:filename, options:options, publish_dir:getSoftwareName(task.process), publish_id:meta.id) }
|
||||
|
||||
// TODO nf-core: Fetch "docker pull" address for latest BioContainer image of software: e.g. https://biocontainers.pro/#/tools/samtools
|
||||
// Click on the Pacakages and Containers tab, sort by Version and get the portion of the link after the docker pull command where Type is Docker.
|
||||
// You may need to double-check that you are using the latest version of the software because you may find that containers for older versions have been rebuilt more recently.
|
||||
// If required, multi-tool containers may also be available and are usually named to start with "mulled".
|
||||
container "quay.io/biocontainers/samtools:1.10--h9402c20_2"
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue