I apparently have been toying with the boundaries of what should be single module vs two. Here we have

snpsift/annmem

which then has a further subcommand

create

. Following nf-core rules I have squeezed it into one module (TIHI): https://github.com/nf-core/modules/pull/9892 similar to how we handle

bbplit/bbmap

alignment and index building: https://github.com/nf-core/modules/blob/master/modules/nf-core/bbmap/bbsplit/main.nf While I don't want my PR to be hold up by discussion, maybe we can use it to see if we need to relax some of the guidelines here to have fewer monstrosities. (I pinky promise, I'll split it out later once we come to a conclusion)

My 2 cents, 2 modules since even if it's just one tool and 1 subcommand, it's really 2 different behaviors

isn't

create

here just a flag that can be passed with ext.args?

I am fairly certain that would make it a lot worse. Because the create command runs parallel task for each database, while the pure annmem command takes all dbs as a list with some special formatting. So maybe with a lot of if/elses we can get the right structure but it will be way less readable than now on what's going on

I see..I blame the developers for not making different/easier commands then :p

I think it should be two modules, as I stated in the PR. I can't see anything in the guidelines that describes what a module should be?

Yeah in my mind this should have been snsift/annmencreate snpsift/annmemrun (or just annmem)

https://nf-co.re/docs/tutorials/nf-core_training/writing-nf-core-modules/chapter-3-what-is-a-nf-core-module#contents-of-an-nf-core-module it's only in the training. I could have sworn that it's an actualy guideline somewhere. Don't even need claude to hallucinate 😄 I shall split this out into two modules then after my next meeting

Ha, funnily enough you're right - it's never explicitly described

maybe between various docs rewrites/movings it disappeared

It's only implicitly defined with: https://nf-co.re/docs/guidelines/components/modules#use-of-multi-command-piping

Software that can be piped together SHOULD be added to separate module files unless there is a run-time, storage advantage in implementing in this way.

yes will do so. So we will say something like: Unless absolutely necessary the finest level of granularity is tool/subtool. Exceptions: subtool flags trigger very different behavior?

Yeah essentially. A module SHOULD represent a single command or single subcommand with a distinct functionality. This is reflected in the name of single execution <tool> or tools with subcommands with <tool>/<subtool> If a tool has mutually exclusive functionality controlled only by flags, the flag name can replace the subcommand. If a tool has sub-sub commands, each subcommand should be appended to the first subcommand. Examples: • Kraken: primary command for execution is

kraken <params>

but also has subcommands for multually exclusive functionalty. Primary execution module is called

kraken2/kraken2

(Note: THIS IS LIKE THE ANNMEM THING) • Kraken: subcommands for

kraken build <params>

. Module is called

kraken2/build

• ANGSD: has a primary command execution and all mutually exlusive functionality are control by arguments, such as

-doCounts

or

-GL

. Modules are

angsd/docounts

angsd/gl

• subsubcommand: cannot remember an example now but something like

aws s3 ls

would be

aws/s3ls

put a reminder for tomorrow. need to leave now

Good enough for now! Could probably make it clearer but it's fine 😉