The `MULTIQC` module has a changed interface, taki...
# modules
d
The
MULTIQC
module has a changed interface, taking only a single parameter, in which a
meta
object is expected as the first value. What's the recommendation for the
meta
object when calling the module from a pipeline? Also, there's now only one entry in the param for configs, while we had two different params earlier (
ch_multiqc_config
and
ch_multiqc_custom_config
) -- can these just be `mix`ed? (I looked in #CE9MS66BS, #CGFUX04HZ and #CE8SSJV3N, but couldn't see that any of them were updated.)
🙇 1
m
see https://github.com/nf-core/tools/pull/4077/changes#diff-c74314588ee95590809a4a5845af217d9e9db1fdfc48d5902e04727cde9544bd on how it will be done in the next template release. otherwise pester @Maxime Garcia and @Matthias De Smet who are responsible for this 🙂
thanks 1
m
and Jon
sorry for throwing you under the bus Jon, but I really think it was the right thing to do
(the tuple, not the bus, obviously)
😆 2
d
I have no problems with this in principle -- in fact, I've seen several cases when a tuple makes more sense than multiple params, IMO -- but maybe it's best for me to downgrade the module and wait for the next release?
m
Basically this all started because I wanted to use a tag for multiQC because we ran multiple MultiQC in #C06PHJM0Y3D, and from there it went downhill and snowballed into this
But similarly to the issue with the imNotifications, we should have waited for a TEMPLATE update to push the changes in the modules repo
d
I didn't say this, but now that you do I can only agree 😉
m
I'd understand if you wish to keep the old MULTIQC, since the only addition is the meta map, and it's a lot of changes outside of the TEMPLATE
p
I also ran into this a few days ago and was banging my head against it for a while
Might even be worth its own blog post, seeing as it's going to affect basically everyone?
💯 3
m
@Matthias De Smet I finally got my chance at breaking everything
🤣 2
m
Glad to have been able to help 😄
😁 1
n
Still can't beat the nf-validation 2.0 situation 😉
💯 2
😁 1
panic mild 1
j
I am dealing with this now and I find it's even worse because if you take the template as an example you have to migrate to using workflow outputs too 🙊
so 💯 in favor of a blog post!
m
ok, that's my job for next week then
I will mention all of you via MEMES
😂 2
d
Coming back to this: Can I ignore the updated module so I don't get linting errors?
m
yeah
No linting errors, no need to update
d
More concrete, what do I do to make linting skip checking this module? It fails now.
m
oh
What's the error now?
d
It's listed among modules whose local copies are not like the remote. Wait a moment and I'll get the message back (linting takes long)
m
You can just run
nf-core modules patch multiqc
👍 1
that way you can have the ‘latest’ version, but with the code patched to the previous iteration
that also fixes the warning that there’s a new version
d
Right,
patch
then
update
m
no, the other way around 😄
update -> edit the module -> patch
That way the correct git commit sha is recorded in
modules.json
d
Of course, subconsciously I wanted to escape the edit I suppose. But, just take a copy, update,
mv
and patch
m
If you want that you can run the install with the `--sha`flag
that way you can specify the exact commit you want
party this 1
nf-core modules install multiqc --sha 9656d955b700a8707c4a67821ab056f8c1095675
You have to live with the warning that there’s a new version available then though
d
I see. I've actually never needed that but have been thinking that the possibilty might be there.
m
I’ve added the sha you need in the cmd above
thanks 1