Modules which pipe multiple commands in a flexible manner (e.g. samtools/multicommand)

Yes, provided that it only works within one chainable suite of tools. Modules for arbitrary shell pipelines (think

bcftools | awk | grep | sort

) should stay in

modules/local

What about naming?

For naming, samtools/pipeline or samtools/multicommand IMO.

And if in some cases you need to repeat steps?

There's no reason the module can't just be 5 repeated calls to

samtools view

Do we have relevant PRs?

No PR yet, module code would definitely need some more love first

Not

samtools/pipeline

😐

When you agree to the name I maybe will consider it

samtools_multicommand samtools_chainedcommand samtools_pipedcommand A few options

Meh, I don't think they are very descriptive though. The chained and piped is slightly better

What do you need the name to encapsulate? Honestly I like the “custom” variants because they’re ugly enough to encourage any user to import them with a sensibly descriptive name

Intent, or the action it is doing

samtools_commandbuilder samtools_constructcommand

Customcommand is too vague, from the point of view a developer might understand how they could customise it. But a user needing to configure it wouldn't know what it is doing and how to e.g fix/customise memory or CPU issues etc. You would ideally need to try and push developers to use aliases to describe exactly what that instance of the module is trying to solve This is sort of minor, but I think it's still a consideration to be made for breaking our current scope of modules

You would ideally need to try and push developers to use aliases to describe exactly what that instance of the module is trying to solve

I don't think that's necessarily a large hurdle, but I agree that it might otherwise be hard to figure out for a user how to tune "SAMTOOLS_CUSTOMCOMMAND" or similar. But at the same time, samtools is pretty good about spilling to disk and not OOMing, so it might not be such a big problem in the first place?

What about grouping these kinds of modules under some umbrella folder like

chain

so you would have

CHAIN_SAMTOOLS

instead. These probably won't have subtools since the idea is to chain subtools.

I don't know that I like that, personally - a module like this just runs samtools, so it would be slightly odd/less discoverable for it not to be grouped with the other samtools modules IMO

It makes sense for us, but as a user, I would expect all samtools modules to be in

samtools

. The website will find it either way, but people might look for modules directly on GitHub as well.

I think discoverability is generally an issue. I still need to do

nf-core modules list remote | grep "tool"

to see what's implemented often

I either do that or go to nf-co.re/modules