feat: add "qualimap bamqc" wrapper

[mobilegenome]

Description

qualimap bamqc is a tool to provide comprehensive quality control reports for alignments in BAM format.

The wrapper repository already contains a wrapper for qualimap rnaseq, this PR migrates this wrapper for bamqc.

QC

• I confirm that:

For all wrappers added by this PR,

• there is a test case which covers any introduced changes,
• input: and output: file paths in the resulting rule can be changed arbitrarily,
• either the wrapper can only use a single core, or the example rule contains a threads: x statement with x being a reasonable default,
• rule names in the test case are in snake_case and somehow tell what the rule is about or match the tools purpose or name (e.g., map_reads for a step that maps reads),
• all environment.yaml specifications follow the respective best practices,
• wherever possible, command line arguments are inferred and set automatically (e.g. based on file extensions in input: or output:),
• all fields of the example rules in the Snakefiles and their entries are explained via comments (input:/output:/params: etc.),
• stderr and/or stdout are logged correctly (log:), depending on the wrapped tool,
• temporary files are either written to a unique hidden folder in the working directory, or (better) stored where the Python function tempfile.gettempdir() points to (see here; this also means that using any Python tempfile default behavior works),
• the meta.yaml contains a link to the documentation of the respective tool or command,
• Snakefiles pass the linting (snakemake --lint),
• Snakefiles are formatted with snakefmt,
• Python wrapper scripts are formatted with black.

[fgvieira]

IS the output just a HTML/PDF report? If so, it would be better to specifically name the output file, instead for the output folder.

[mobilegenome]

I looked into this. The output file is always named genome_results.txt inside the directory currently specified. I think it would be confusing if the output file would be specified in the rule. This would create the impression the filename could be changed, and lead to errors if a different name would be specified. Thus, I would suggest to keep the output as directory.

[fgvieira]

But is it the only output file?
Alternatively, we could set the output folder to a temp folder (using tempfile) and at the end, depending on which output files were specified, copy them to their final destination (e.g. like in star).

[mobilegenome]

This is actually a very good suggestion, but unfortunately it breaks the MultiQC compatibility that is based on exact file namings of the TXT and HTML reports based on the programs default. As I assume MultiQC is a major use-case of bamqc, it is definitly the better option to use the directory directive instead of specifying exact filenames.

I've add a parameter to create HTML reports by defaults, as these are also parsed by MultiQC and documented its use.

[fgvieira]

But that then would be up to the user to properly define the output file name, no?
I was just wondering if, under some circumstances, the user might want to have different files placed in different places.

[mobilegenome]

Hi @fgvieira, I don't mean to push this review - but while my mind is still fresh on the topic - wanted to ask if there are any more concerns or if I can provide more information/changes to make it pass. :)

[fgvieira]

I tend to always avoid directory() and refer to the output files directly, since it allows to reference specific files in downstream rules and mark unnecessary files as temp().

Also in the PR checklist, it states that:

• input: and output: file paths in the resulting rule can be changed arbitrarily,

but not sure if it refers to single files or also to folders, or how much @johanneskoester wants to enforce it.

As for the rest, I think it looks great! 😄

[johanneskoester]

Sorry folks. I merged this accidentally before these have been fixed. I'll fix them myself now since it was my fault.

[johanneskoester]

Ok, actually having it as a dir is correct, since this is just an HTML folder hierachy. Nevertheless, I have added a sample report marker so that is becomes more obvious how to use this in a typical workflow.
#539

[johanneskoester]

Thinking about it, nowadays people might rather use it via multiqc. Hence, I will close my PR and leave it as it is.