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

nf-core

Could I get a second opinion on this? <https://github.com/nf-core/modules/pull/12187#discussion_r3688678552|github.com/nf-core/modules/pull/12187#…>
It's about having the `versions.yml` as an optional file. The module likely has it's compute environment changed when integrated into a pipeline. This then means it's down to the quarto script itself to write out the versions. This could mean either the module gets patched with output channels for each version, or the input script should write a versions.yml. What would your opinions be on this. The module also renders part of a document, that should be rendered again with the same tool in another process.

Personally don't like the idea of using `versions.yml` at all if we can avoid it. 

Does it not make sense to just set eval(s) for any tool(s) which are always used e.g. quarto, papermill and then have a comment similar to the container one telling people to patch in extra ones depending on the tools they use? 

we need versions.yml for modules that use a template (R/python) anyway

Hopefully we will be able to ditch that in the future too

So what should we do? Force versions.yml or request patching? It's currently quite easy to forget to include versions.

I've come to the conclusion that the qmd should write a versions.yml and it should not be optional. This gives a real failure mode to make sure the reports write out a versions which requesting a module patch would not do.

Possibly irrelevant side note in case it figures into the thinking:

In diff. ab. we use the Quarto report as the main reporting mechanism, consuming the `versions` topic indirectly. The process can't then emit to the versions topic without creating a loop and an error. We had to <https://github.com/nf-core/differentialabundance/pull/707/changes/8bd8e835471e105129db6330e01f235da0ff8fcb|patch around> to avoid the problem.