feat(coverm/{contig,genome}): add bam output

[dialvarezs]

This PR adds BAM output to coverm modules via the enable_bam_output input flag that triggers the --bam-file-cache-directory option with a fixed directory. The contents of this directory are emited as an optional output.

PR checklist

• 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.
• Broadcast software version numbers to topic: versions - See version_topics
• 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

[jfy133]

Main concern is the the empty lists in the tests, but otherwise minor commetns

[jfy133]

Should this be empty?

[dialvarezs]

Empty list is because the bam output is optional. If it's not enabled, then the list is empty

[jfy133]

Another empty list...

[jfy133]

Empty list...

[jfy133]

And again

[famosab]

Thank you for your contribution to nf-core! We really appreciate it. I added a few comments to your PR.

[famosab]

Looks good I added a few more comments.

I am wondering whether there is even a better way to handle short vs long read bams in the way we structure the output. And if we are able to control the bam file naming.

[famosab]

Can we put all these inputs into one tuple? That will make sure you're sure that EVERY time everything comes together in the right combination.

[dialvarezs]

You mean this?

tuple val(meta), path(input), path(reference), val(bam_input), val(interleaved), val(enable_bam_output)

I'm not so sure about that. In my opinion that would introduce extra complexity in the workflows, because you will have to build the channel by joining/combinig all together.
And other similar modules use this pattern too: minimap2, bwa, bowtie. All of them separates the reads, the reference and additional flags as separate inputs.

[famosab]

I get that, we just try to converge more on that because the combine statements make sure that the channels do not get mixed up, but its more of a goal and not something I would enforce here.

[prototaxites]

I don't think it's a bad idea to put most of these as a single input, as they're sample-dependent vals - but presumably enable_bam_output is something you'd want to configure once as a single input?

[dialvarezs]

@famosab @jfy133 can I get a ✅ then?

[dialvarezs]

Thanks @jfy133!