Add starting deseq2 differential module

[pinin4fjords]

This PR adds a wrapper for DESeq2. Notes:

• Implemented as a template, initially due to need to include a wrapper script and current lack of module bin directory (see https://nfcore.slack.com/archives/CJRH30T6V/p1665066826554919)
  • I think this actually works better than use of a module bin, because we don't need an additional library to provide a CLI! So here we can just use the biocontainer for DESeq2 and nothing else, no need to create bespoke containers etc.
• Optional params can be supplied via the usual task.ext.args route, and are handled within the template.
• I've defined contrasts with a groovy map, in an analagous way to sample meta in other workflows, comprising:
  • variable - a variable from the supplied sample sheet that can be used to group samples
  • reference - level of contrast variable indicating 'reference' samples.
  • target - level of contrast variable indicating 'target'/ 'treatment' samples.
  • blocking - comma-separated list of blocking variables to be included in the model.
• A test expression matrix was added to the test data here.
• Tiny variations between machines at the 12th decimal point (or so) in some test outputs were causing the CI to fail. So I've just added some very limited rounding to ensure the reproducibility, which can be activated specifically in the CI context.

PR checklist

Tackling #2155

• Adds module for differential expression analysis with DESeq2
• If you've fixed a bug or added code that should be tested, add tests!
• If you've added a new tool - have you followed the module conventions in the contribution docs
• If necessary, include test data in your PR.
• Remove all TODO statements.
• Emit the versions.yml file.
• Follow the naming conventions.
• Follow the parameters requirements.
• Follow the input/output options guidelines.
• Add a resource label
• Use BioConda and BioContainers if possible to fulfil software requirements.
• Ensure that the test works with either Docker / Singularity. Conda CI tests can be quite flaky:
  • PROFILE=docker pytest --tag <MODULE> --symlink --keep-workflow-wd --git-aware
  • PROFILE=singularity pytest --tag <MODULE> --symlink --keep-workflow-wd --git-aware
  • PROFILE=conda pytest --tag <MODULE> --symlink --keep-workflow-wd --git-aware

[pinin4fjords]

@nf-core-bot fix-linting

[pinin4fjords]

@nf-core-bot fix linting

[nvnieuwk]

Did you use the nf-core modules create tool to create this module? The test files are absent in this PR (which is why some of the actions aren't running)

[pinin4fjords]

Did you use the nf-core modules create tool to create this module? The test files are absent in this PR (which is why some of the actions aren't running)

I'll get there- just a WIP for visibility and discussion, I'll get things tested before requesting formal review.

[nvnieuwk]

Maybe change this to a draft PR then :)

[pinin4fjords]

@nf-core-bot fix linting

[pinin4fjords]

@nf-core-bot fix linting

[pinin4fjords]

(note: singularity failure is just because we're waiting for a build to propagate from biocontainers)

[ggabernet]

Looks good to me! As mentioned in slack there are some features missing that we would like to include but it's good to start with a minimal POC!
One thing that could be done to also test the blocking variables and that the execution with multiple contrasts works fine would be to add another contrast in the example data with a blocking variable provided.

[pinin4fjords]

Thanks @ggabernet! I'm just going to switch the inputs to be keyed by the meta- as per feedback in #2321, will do that quickly now.

[pinin4fjords]

One thing that could be done to also test the blocking variables and that the execution with multiple contrasts works fine would be to add another contrast in the example data with a blocking variable provided.

@ggabernet Good point- modifications to the test data here: nf-core/test-datasets#670

[ggabernet]

Actually this would be important only in the case that the files are initially provided to the pipeline with a samplesheet (e.g. multiple fastq files to analyze, each of them with individual sample metadata that is passed to the meta map).
In the case of the differentialabundance pipeline, we expect to have just 1 count table with all samples to analyze. The samplesheet containing info about the different samples will be provided to the module input. Therefore I would argue that we will not need the meta map here.

In the case of the other module that you mentioned #2321 that operates on reference data (e.g. reference GTF or fasta) and not on sample (sequencing) files, the meta maps would not be needed either.

[pinin4fjords]

Thanks @ggabernet (and apologies I just saw this). I was confused in the other review - it seemed like the meta thing was pretty non-negotiable (though as it turned out I think there was a use for it there).

In the latest commits I've put the inputs in a single tuple with the 'contrast meta' as the 'meta' rather than a separate channel for the contrast meta, which I think is nicer, but happy to reverse that if you like.

(and the additional contrast with blocking factor is now tested too)

[ggabernet]

ok sure, looks good to me like this too!

[pinin4fjords]

Thanks for the review @ggabernet !