mirror of
https://github.com/MillironX/nf-core_modules.git
synced 2024-12-22 11:08:17 +00:00
Add software dependencies and version string to requirements list
This commit is contained in:
parent
4ee6ddc7ab
commit
fe882f1579
1 changed files with 29 additions and 16 deletions
45
README.md
45
README.md
|
@ -7,12 +7,12 @@ A repository for hosting nextflow [`DSL2`](https://www.nextflow.io/docs/edge/dsl
|
||||||
## Table of contents
|
## Table of contents
|
||||||
|
|
||||||
- [Using existing modules](#using-existing-modules)
|
- [Using existing modules](#using-existing-modules)
|
||||||
- [Configuration and parameters](#configuration-and-parameters)
|
- [Configuration and parameters](#configuration-and-parameters)
|
||||||
- [Offline usage](#offline-usage)
|
- [Offline usage](#offline-usage)
|
||||||
- [Adding a new module file](#adding-a-new-module-file)
|
- [Adding a new module file](#adding-a-new-module-file)
|
||||||
- [Testing](#testing)
|
- [Testing](#testing)
|
||||||
- [Documentation](#documentation)
|
- [Documentation](#documentation)
|
||||||
- [Uploading to `nf-core/modules`](#uploading-to-nf-coremodules)
|
- [Uploading to `nf-core/modules`](#uploading-to-nf-coremodules)
|
||||||
- [Help](#help)
|
- [Help](#help)
|
||||||
|
|
||||||
## Terminology
|
## Terminology
|
||||||
|
@ -27,7 +27,7 @@ The features offered by Nextflow DSL 2 can be used in various ways depending on
|
||||||
|
|
||||||
The Nextflow [`include`](https://www.nextflow.io/docs/edge/dsl2.html#modules-include) statement can be used within your pipelines in order to load module files that you have available locally.
|
The Nextflow [`include`](https://www.nextflow.io/docs/edge/dsl2.html#modules-include) statement can be used within your pipelines in order to load module files that you have available locally.
|
||||||
|
|
||||||
You should be able to get a good idea as to how other people are using module files by looking at pipelines available in nf-core e.g. [`nf-core/rnaseq`](https://github.com/nf-core/rnaseq/pull/162)
|
You should be able to get a good idea as to how other people are using module files by looking at pipelines available in nf-core e.g. [`nf-core/chipseq`](https://github.com/nf-core/chipseq/tree/dev) (work in progress)
|
||||||
|
|
||||||
### Configuration and parameters
|
### Configuration and parameters
|
||||||
|
|
||||||
|
@ -54,21 +54,34 @@ nextflow run /path/to/pipeline/ -c /path/to/custom_module.conf
|
||||||
|
|
||||||
## Adding a new module file
|
## Adding a new module file
|
||||||
|
|
||||||
If you decide to upload your module file to `nf-core/modules` then this will ensure that it will be automatically downloaded, and available at run-time to all nf-core pipelines, and to everyone within the Nextflow community! See [`nf-core/modules/nf`](https://github.com/nf-core/modules/tree/master/nf) for examples.
|
If you decide to upload your module file to `nf-core/modules` then this will ensure that it will be automatically downloaded, and available at run-time 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) for examples.
|
||||||
|
|
||||||
The definition and standards for module files are still under discussion amongst the community.
|
The definition and standards for module files are still under discussion amongst the community.
|
||||||
|
|
||||||
Currently the following points have been agreed on:
|
Currently the following points have been agreed on:
|
||||||
|
|
||||||
- Module file should only define inputs/outputs as parameters and have the ability to use `params.MODULENAME_options` as an additional parameter to add any additional settings via pipelines.
|
- Module file should only define inputs/outputs as parameters and have the
|
||||||
- Specify single-end boolean values within the input channel and not be inferred from the data e.g. [here](https://github.com/nf-core/tools/blob/028a9b3f9d1ad044e879a1de13d3c3a25a06b9a7/nf_core/pipeline-template/%7B%7Bcookiecutter.name_noslash%7D%7D/modules/nf-core/fastqc.nf#L13)
|
ability to use `params.MODULENAME_options` as an additional parameter to add
|
||||||
- Define threads or resources where required for a particular process using `task.cpus`
|
any additional settings via pipelines.
|
||||||
- Software that can be piped together should be added to separate module files unless there is an run-time, storage advantage in implementing in this way e.g. `bwa mem | samtools view` to output BAM instead of SAM
|
- Specify single-end boolean values
|
||||||
- Process names should be all uppercase
|
within the input channel and not be inferred from the data e.g.
|
||||||
|
[here](https://github.com/nf-core/tools/blob/028a9b3f9d1ad044e879a1de13d3c3a25a06b9a7/nf_core/pipeline-template/%7B%7Bcookiecutter.name_noslash%7D%7D/modules/nf-core/fastqc.nf#L13)
|
||||||
|
- Define threads or resources where required for a particular process using
|
||||||
|
`task.cpus`
|
||||||
|
- Software that can be piped together should be added to separate
|
||||||
|
module files unless there is an run-time, storage advantage in implementing
|
||||||
|
in this way e.g. `bwa mem | samtools view` to output BAM instead of SAM -
|
||||||
|
Process names should be all uppercase
|
||||||
- The `publishDirMode` should be configurable
|
- The `publishDirMode` should be configurable
|
||||||
- Test data is stored within this repo. Re-use generic files from `tests/data` by
|
- Test data is stored within this repo. Re-use generic files
|
||||||
symlinking them into the test directory of the module. Add specific files
|
from `tests/data` by symlinking them into the test directory of the module.
|
||||||
to the test-directory directly. Keep test files as tiny as possible.
|
Add specific files to the test-directory directly. Keep test files as tiny as
|
||||||
|
possible.
|
||||||
|
- Software requirements should be declared in a conda `environment.yml` file,
|
||||||
|
including exact version numbers. Additionally, there should be a `Dockerfile`
|
||||||
|
that containerizes the environment.
|
||||||
|
- Each process should emit a file `TOOL.version.txt` containing a single line
|
||||||
|
with the software's version in the format `vX.X.X`.
|
||||||
|
|
||||||
### Testing
|
### Testing
|
||||||
|
|
||||||
|
@ -80,7 +93,7 @@ Please add some documentation to the top of the module file in the form of nativ
|
||||||
|
|
||||||
### Uploading to `nf-core/modules`
|
### 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/nf`](https://github.com/nf-core/modules/tree/master/nf) directory. Please keep the naming consistent between the module and documentation files e.g. `bwa.nf` and `bwa.md`, respectively.
|
[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. Please keep the naming consistent between the module and documentation files e.g. `bwa.nf` and `bwa.md`, respectively.
|
||||||
|
|
||||||
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 `nf-core/modules` GitHub repo with the appropriate information.
|
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 `nf-core/modules` GitHub repo with the appropriate information.
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue