(only?) two nf-core modules are using `topic: mult...
# team-maintainers
e
(only?) two nf-core modules are using
topic: multiqc_files
. What was the consensus; do it in the modules or downstream in the pipelines?
l
I guess this is a @Maxime Garcia consensus 😄 But personnaly, I think this could be nice, even though multiqc_files might not be the best way to describe these files (
qc_files
). The only issue to do so, would be that if you run these modules you would necessarily have them in your multiqc, you can't opt-out.
e
true true, except if you patch them locally
m
It's a me thing indeed, I wanted that in all modules, but was not fully allowed
e
You have +1 from me
m
You can tell multiqc which modules to check for. It is possible to exclude things, but would mean the pipeline maintainer needs to spend time configuring MQC
Filesystems with inode limits though might encounter problems.
m
It's possible to filter out things from topics if you want to
m
True, but who wants to include lines of
.filter
for everything they don't want.
m
I see your point
Anyhow, I am more interesting in having citations info in meta.yml than multiqc_files topics
So I am willing to compromise between the things I want
Give me one, I'll back down on the other
Otherwise, I'll fight to get all the things
❤️ 1
all the things
#C0749PAEU9F
m
by citations you mean automatically collating all the citations from individual modules/subworkflows ? 💯 from me
m
yeah, like I do already in #C06PHJM0Y3D, we need to continue full proofing the logic in #C08TKFDUNHG with @Edmund, but we are almost there
👍 1
m
I kind of feel like we need two files. One tool.yml that lives in the module root that has the docs and meta, and citation links, and then the meta.yml itself with the module specific info.
👀 1
🚀 1
Isn't the info hosted somewhere else though? I thought EDAM or some ontology had all this info
m
yeah, EDAM has some info indeed
and bio.tools too
m
That's the one