Sorry for slight spam about the monster bgzip PR, but it touches upon some cans of worms. One that I think deserves some discussion is "`val` inputs for things that are not quite tool inputs, but not

ext.args

either". This includes several aspects: enabling optional outputs, setting output formats, controlling postprocessing steps, and selecting one of several actions of a tool. They are used in a minority of modules, but a non-negligible one: according to a quick AI-powered semantic search, 69 modules currently have an input channel of this kind (some examples:

minimap2/align

,

fastp

,

sourmash/gather

,

bwa/mem

,

salmon/quant

). As of today, there is no specific guidance on this topic in the module specification. I think we should establish some rules on this, since currently it's seemingly handled ad hoc. What do you think about this?

What are other practices are there other than as

input:

? What kind of guidance do you want to document specifically?

The main alternative to

input

is

task.ext

, a solution with little support in the community and limited to certain types of optional inputs. My problem is that we currently have no documented good practices for this kind of input: the docs only specify "file inputs" and "mandatory non-file inputs", with the instruction to provide everything else through

task.ext.args

. This covers most situations, but not all. Two cases that stand out are behavior flags (

compress

,

sort

,

save_bam

, etc.) and output file extensions – neither of which is really an argument for the command itself. I don't necessarily want to change any practices, but rather state plainly that: • non-mandatory non-file inputs can be fine if they don't reasonably fit into

ext.args

• the correct mechanism for setting output formats is a

val

input, not any other hack • perhaps more controversially, for modules with more than one behavior, flag-like (

save_X

,

compress

) or enum-like (

action

,

subcommand

) inputs are okay, as long as they relate to behaviors that the average user would expect

I guess I see the

ext

as something very specific which I realise many don't distinguish. For me the

ext

map is the only means in which a pipeline user can provide a dynamically controlled string into a script. If a pipeline user doesn't need dynamic manipulation of the string it should be an

input:

, perhaps becoming user exposed with a parameter. However more documentation is always welcome. Navigating nf-core docs content to find it is still an issue, but at least if some people know where it's located, it can be pointed to.

I will try to put my thoughts into a website PR that we could further discuss

Thanks for the reminer, @Igor Trujnara. I’m ok with it 👍