fix: for vsearch, fixed bug with bz2 output and added general log

[fgvieira]

Description

Fixed bug with bz2 output and added the general log too keep console clean and be able to keep track of progress.

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.
• Conda environments use a minimal amount of channels, in recommended ordering. E.g. for bioconda, use (conda-forge, bioconda, nodefaults, as conda-forge should have highest priority and defaults channels are usually not needed because most packages are in conda-forge nowadays).

[fgvieira]

Failing due to ensembl_sequence_chromosomes wrapper.

[fgvieira]

I thought a bit more about the log file and, since it is not exactly the same as the stdout, it makes sense to support it. However, I think having it as verbose might be a bit confusing since it is not clear where that output comes from.
If we leave it an optional output, then it is clear it comes from the vsearch command line argument log (just like all the other outputs).

[johanneskoester]

Mhm, but it will be lost upon error. log is really the right place for these things. If you don't like verbose, maybe call the two logs std and vsearch?

[fgvieira]

That is true, the outputs are lost in error.