A community effort to collect a curated set of analysis pipelines built using Nextflow.

nf-core

Hi, about the issue with `rich.panel.Panel` <https://github.com/MultiQC/MultiQC/issues/3536>
Has the patch been pushed on conda? Thanks!

It's not in a release (yet), so not on Conda. <@UE4L64T4G> can tell us when the next release is likely.

But FYI if you're seeing this you likely have an underlying issue, this comes up in the process of error reporting.

You could add a pin to your local copy of the multiqc module in whatever workflow you're using, in the environment.yml:

```dependencies:                                                                                                                                                                              
    - bioconda::multiqc=1.34
    - conda-forge::rich=14.2```
That will surface whatever your actual problem is

Can you guys explain what problem this is causing? I was under the impression it was a fairly rare edge case?

It's a bug in exception handling rather than core MultiQC stuff like plotting, caused by dependency drift. So it will happen when folks have underlying problems (and use a newly built env)

<@U0B0T5D4WN4> can you elaborate why you need the patch pushed on conda? :sweat_smile:

<@UE4L64T4G> the code from bioconda has still the bug

so when we test multiqc with nf-core pipelines, it fails because of the issue with the exception.

I had to set rich==14.2.0 in <http://environment.to|environment.yml>  to make it work

What error did MultiQC show you when you did?

(just confirming that I'm correct in saying that you have some other issue in parallel)

the same with rich.panel.Panel reported in the issue <https://github.com/MultiQC/MultiQC/issues/3536>

<@U03SLE7RBAS> yes it's the one you were talking about. Indeed, I used the same workaround you suggested.

Sorry, to re-phrase.

My understanding of this issue is that it is with error handing. So if you check your multiqc log AFTER this fix you should see the errors that the problem with exception handling was masking. It may not be lethal, so you may have to check that log to find the problem.

It was a trigger done on purpose with no dataset to plot

Ahh, OK. So if you don't engineer a failure in that way you don't actually have a problem, yes?

That's what Phil's asking- let's not make him rush a release out unless it's crucial.

Yes, no issues with multiQC once we force rich==14.2.0

What I mean is, if you run the un-fixed version, and don't create a problem with the MultiQC inputs, you don't trigger this problem, correct?

Ah yes, if I don't trigger the call to rich.panel.Panel, then everything works fine.

So in normal circumstances everything works fine

OK cool, thanks. That's the difference between Phil panicking and shoving a release out, or not. Since this is only triggered in the presence of non-multiqc problems I think this can wait until Phil's next routine release.

yes, sorry for misunderstanding your questions :slightly_smiling_face: