feat: add literal string to make contrasts in variancepartition/dream

[atrigila]

POC of nf-core/differentialabundance#386

Current implementation is:

• If comparison is provided, then it is passed as a literal string to limma::makeContrasts.
• Otherwise, the previous design remains.
• The comparison is only used in inputs.contrasts_for_diff_with_formula, which is the input to VARIANCEPARTITION_DREAM in ABUNDANCE_DIFFERENTIAL_FILTER for now.

@grst , when you have a chance, could you take a look and let me know if this implementation makes sense? If anything needs updating, I’m happy to make the changes.

PR checklist

Closes #XXX

• This comment contains a description of changes (with reason).
• 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:
  • For modules:
    • nf-core modules test <MODULE> --profile docker
    • nf-core modules test <MODULE> --profile singularity
    • nf-core modules test <MODULE> --profile conda
  • For subworkflows:
    • nf-core subworkflows test <SUBWORKFLOW> --profile docker
    • nf-core subworkflows test <SUBWORKFLOW> --profile singularity
    • nf-core subworkflows test <SUBWORKFLOW> --profile conda

[grst]

Few, minor things

[pinin4fjords]

Making optional things mandatory in module and subworkflow inputs complicates workflow logic. Suggest this new thing goes via ext.args, passed from meta at the workflow level.

This is how blocking variables are handled in deseq2, for example.

Edit: this is more complex than I'd considered- see discussion below. I think this will be OK after resolution of minor points.

[pinin4fjords]

Convention in nf-core is for non-mandatory non-file things to go in via ext.args. Otherwise people end up having to supply '[]' or '' or other messy things.

[pinin4fjords]

Doing that would also mean you don't need to change the workflow logic, you can pass it from the meta when it's available.

[grst]

Perspectively, wouldn't that also mean that contrast_variable, reference, and target should go to ext.args? Technically they are not needed when a formula and contrast string are provided. See also nf-core/differentialabundance#451

[pinin4fjords]

Yes, I suppose that's true. But it might be simpler to leave those in place for now and resolve separately. I'm mostly concerned with not adding additional subworkflow complexity for this.

[pinin4fjords]

@atrigila @grst I chatted with the maintainers, and the consensus was that in a situation where e.g. A + B OR C + D were required, a sensible thing might be to have two separate input channels. But this is not the case here, since these can be somewhat overlapping (right)?

Let's keep your version for now, I hadn't considered this point of Gregor.

[grst]

In a future version they'll be mutually exclusive. But sounds good to keep it as is for the current iteration.

[pinin4fjords]

I think we may end up adjusting this stuff to more cleanly handle the different ways of specifying contrasts. But I think it's OK to run with this for now and see how you go