Repository for snakemake rules concerning tools and workflows
This repository aims to gather all Snakemake descriptions. They all try to follow some rules in order to make them easily reusable from one workflow to another.
Thus, the repository is splitted in two sections:
*[__tools__](tools/): All tool descriptions. These are not meant to be used directly and need to be refered in another Snakefile
*[__subworkflows__](subworkflows/): Supposed to behave as tool descriptions, meaning that they need to be refered in another Snakefile to be used.
*[__workflows__](workflows/): All workflows that are supposed to be usable directly
Similar to tools, subworkflows cannot be used directly but need to be called in a higher Snakefile
by setting up the required variables.
## Design and best practices
All subworkflows are described in a `Snakefile` in a directory having its name.
All Snakefiles try to respect some rules and best practices in their design:
* Snakefile paths
* Set up different parameters for tool rules
### Snakefile paths
All `Snakefile` path can be configured in the `config.yaml` file but have default value that are relative path in this repository.
### Set up different parameters for tool rules
Then for every tool, it should have some input and output to specify. (_ref to tools directory README for more information_).
As for the tool descriptions, input and output for subworkflows are abstracted using the nomenclature `__SUBWORKFLOW_NAME_input` and `__SUBWORKFLOW_NAME_output`.
For intermediate tools, you can then easily link output and input:
This directory contains every workflows built from Snakemake tool found in the `tools` directory of the repository.
This directory contains every workflows built from Snakemake tool and subworkflows found in the `tools`and `subworkflows`directories of the repository.
## Design and best practices
All the Snakemake workflows try to respect some rules and best practices in their design.
Therefore, workflows have the following parts:
1.reference to `config.yaml` file
2.reference to tool rules
3.set up of common variable for the workflow
4.set up of specific variables for the tools
1.Reference to options from a `config.yaml` file.
2.Snakefile paths
3.Set up of common variable for the workflow
4.Set up of specific variables for the tools
5.`rule all` to specify what is/are the specific file(s) expected from the workflow.
#### Reference to tool rules
### Reference to options from `config.yaml` file
The location of the tools included in the workflow can vary depending your organization.
Therefore, we decide to put every references at the begining of the workflow to make it easy
to customize and change if necessary.
First part correspond to all options that are set up from a `config.yaml` file. They all have the nomenclature `__TOOLNAME_variable`.
#### Set up common variable for the workflow
Then in the YAML `config.yaml` file, you can set the variable as followed:
```yaml
TOOLNAME:
variable:4
```
We recommend to use the `get` method to access this parameter and set a default value:
```python
config['TOOLNAME'].get('variable',1)
```
### Snakefile paths
All `Snakefile` path can be configured in the `config.yaml` file but have default value that are relative path in this repository.
### Set up common variable for the workflow
Then every common variables are set up. This can be handy for reference to a common directory.
#### Set up specific variables for the tools
### Set up specific variables for the tools
Every specific variables for every tools are then specified. For more details about the way
every tool is describe, you can refer to the `README` of the `tools` directory of the
...
...
@@ -62,4 +77,6 @@ Then, to run a `SnakeFile` on Tars we use a command similar to the following:
