Module parameter inheritance and parameter wrapping about modules HOT 4 CLOSED

Copied from Slack:

As ugly as it sounds I think the easiest and possibly the most flexible option is to only define inputs and outputs in the actual module file and no other parameter definitions (other than --threads $task.cpus maybe). This follows the NF philosophy quite well.

Additional parameters would then be provided by a string of some sort with the hope that the downstream tool validates these parameters! Would be nice if we can make the variable name for optional parameters standardised e.g. --<MODULE_NAME>_options.

from modules.

Agreed - my way of saying basically the same thing (I think) is this:

I think that the default module command should be as simple as possible, with dedicated parameters for the required options (will often not be any if the essential options are covered by input and output channels). Then any additional optional flags could go in a generic string param as @drpatelh suggests above.

So using the cutadapt example above, if it was impossible to run cutadapt with the -a flag then we would have params.cutadapt_adapter_sequence and then --cutadapt_options for everything else.

As mentioned on slack, the addParams thing is cool, but I can see it struggling with edge cases such as hyphens in command-line parameters (hyphens are not allowed in groovy variable names) and other random stuff. I agree that although the generic string approach is ugly, it's also the simplest to maintain and least likely to go wrong.

Remember that pipeline authors can make these generic strings however they like, so can define their own convenience params for users where applicable.

Phil

from modules.

Note that @FelixKrueger is using the "simple string" approach in his DSL2 modules. See #30 for example.

Also note that starting with the "simple string" approach is not incompatible with manually adding other params - these can be added on to that string as done in #28 - though maybe we should avoid this and keep things simple (at risk of being a complete hypocrite here, sorry).

from modules.

We have agreed on passing all optional parameters via an options.args string and this seems to be working really well. Especially as it allows for optional parameters to be overwritten at both the user and developer level via custom configuration files.

from modules.