Fix MultiQC output file name

[marcelm]

For some reason, MultiQC 1.18+ bases the output file name on the report title. To get the old behavior, one needs to configure the output file names explicitly.

This PR does not actually fix the issue at the moment because output_fn_name is broken in MultiQC 1.19 and MultiQC 1.20 is not yet available on Bioconda.

[cnluzon]

I think it is OK if this is just merged regardless, it will fix on its own soon enough and either way even if the rule fails, the MultiQC output is generated, and this is the last step of the workflow, so everything is already produced by the time it fails.

Otherwise we can just leave it open for a few days and see if bioconda updates the MultiQC version to 1.20.

[marcelm]

It turns out that MultiQC is in fact available from Bioconda, but it conflicts with our version requirements. I have so far narrowed the problem down to a conflict between pillow (required by multiqc) and pysam:

$ conda create -n tmp 'pillow>=10.2.0' 'pysam>=0.22.0'
Channels:
 - conda-forge
 - bioconda
Platform: linux-64
Collecting package metadata (repodata.json): done
Solving environment: failed

LibMambaUnsatisfiableError: Encountered problems while solving:
  - package libtiff-4.6.0-h8b53f26_0 requires libjpeg-turbo >=2.1.5.1,<3.0a0, but none of the providers can be installed

Could not solve for environment specs
The following packages are incompatible
├─ pillow >=10.2.0  is installable with the potential options
│  ├─ pillow 10.2.0 would require
│  │  ├─ libjpeg-turbo >=3.0.0,<4.0a0 , which can be installed;
│  │  └─ libtiff >=4.6.0,<4.7.0a0  with the potential options
│  │     ├─ libtiff 4.6.0 would require
│  │     │  └─ libjpeg-turbo >=2.1.5.1,<3.0a0 , which conflicts with any installable versions previously reported;
│  │     └─ libtiff 4.6.0 would require
│  │        └─ libdeflate >=1.19,<1.20.0a0 , which can be installed;
│  ├─ pillow 10.2.0 would require
│  │  ├─ libjpeg-turbo >=3.0.0,<4.0a0 , which can be installed;
│  │  ├─ libtiff >=4.6.0,<4.7.0a0  with the potential options
│  │  │  ├─ libtiff 4.6.0, which cannot be installed (as previously explained);
│  │  │  └─ libtiff 4.6.0, which can be installed (as previously explained);
│  │  └─ python_abi 3.11.* *_cp311, which can be installed;
│  └─ pillow 10.2.0 would require
│     └─ python_abi 3.12.* *_cp312, which can be installed;
└─ pysam >=0.22.0  is not installable because there are no viable options
   ├─ pysam 0.22.0 would require
   │  ├─ libdeflate >=1.18,<1.19.0a0 , which conflicts with any installable versions previously reported;
   │  └─ python_abi 3.10.* *_cp310, which conflicts with any installable versions previously reported;
   ├─ pysam 0.22.0 would require
   │  ├─ libdeflate >=1.18,<1.19.0a0 , which conflicts with any installable versions previously reported;
   │  └─ python_abi 3.8.* *_cp38, which conflicts with any installable versions previously reported;
   └─ pysam 0.22.0 would require
      ├─ libdeflate >=1.18,<1.19.0a0 , which conflicts with any installable versions previously reported;
      └─ python_abi 3.9.* *_cp39, which conflicts with any installable versions previously reported.

I’m not sure how to proceed.

[cnluzon]

Is there a reason why we need pysam>=0.22.0? I think minute only uses this to our custom mark duplicates according to je results, which is a fairly simple functionality (just iterate through BAM file), so maybe this requirement can be relaxed and resolved to an older version of pysam if that does not conflict. Otherwise MultiQC can just be pinned to older versions, but this seems to be helpful in improving the reports.

Edit to say I tried without specifying pysam version and it went as low as 0.9.1 which might be too old.

Since this is a recent change in MultiQC they might fix something in the environment, because it is not so unexpected that there are a bunch of workflows that use pysam that also use MultiQC. Maybe it should even be reported to them?

[marcelm]

I forgot to say that I had pysam>=0.22.0' version requirement in there only to shorten the error message. Withpysam>=0.14` (as we currently require in the environment file), the message lists also all the other various pysam versions that don’t work.

pysam 0.9.1 seems a bit old indeed.

I’ve asked on the Bioconda chat, but haven’t received a reply so far.

[cnluzon]

If this package incompatibility does not have a fix at the moment, maybe the best solution for the time being is to pin MultiQC to an older version, like MultiQC 1.17, when this renaming issue didn't exist.

[marcelm]

Yeah, good point. I pushed an appropriate commit. I suggest to leave in the changes to the multiqc configuration file so that we don’t have to re-do this when we bump to a more recent MultiQC.