@Evangelos Karatzas and I could use some input on what nf-core's best practices are with regards to module complexity for tools with subcommands. I.e., should modules be as simple as possible and do one thing only? Or should they encapsulate an entire main command of a tool, and offer enough input options to tweak this for different subcommands? My fear for the latter is that it can get out of hand (e.g., I remember I had difficulties understand how the bbsplit index module was intended to be used at first), but for tools with many subcommands, the number of modules (with a lot of similar boilerplate) grows too. I've implemented both approaches and provided more details here: https://github.com/nf-core/modules/pull/10027

Btw, i am voting for one subcommand that tends to all cases with checks inside. But I know that people might disagree with that..so if you could provide your feedback regarding this case of

deacon index

sub-subcommands.. 🙏

I.e., should modules be as simple as possible and do one thing only

Yes this. We added this recently for better understanding: https://nf-co.re/docs/guidelines/components/modules#module-granularity

Thanks! But I should have clarified a bit more. We're dealing with subsubcommands here. There's

deacon index build <fasta>

,

deacon index build union/intersect <2 or more index files>

, and

deacon index diff <index file> <fasta or index file>

. So same principle, but even more options than just splitting

index

+

main function

like we do for most alignment tools.

I think the same applioes, so

deacon/indexbuildunion

(arguably this is bad design also for the tool) But does it really go so deep?

If a tool has sub-sub-commands, each subcommand SHOULD be appended to the first subcommand.

So that's what we have here. Imo the distinction shouldn't be whether we're dealing with a sub or subsub command, but more whether the inputs/outputs are similar or not.

Yeah exactly, when we define a subcommand we are assuming a subcommand has a sort of mutually exclusive set of inputs/parmaeters

Oh I misread that doc page, it's telling how to name the sub-sub-command, not that functionality should be appended. Still waking up it seems.

Thanks James! Should we still keep the deacon_index on its own? I think it can run on its own as well without another subsubcommand

Yes

(on phone tho now and it's cold, so cant check)

Well let me hceck quickly

One could argue that build is the main (and) expected purpose. And then we'd keep backwards compatibility?

Can also do that