External Argument Documentation

[charlesdavid]

Description of feature

Given that the modules.config file contains the following:

Available keys to override module options:
ext.args = Additional arguments appended to command in module.
ext.args2 = Second set of arguments appended to command in module (multi-tool modules).
ext.args3 = Third set of arguments appended to command in module (multi-tool modules).
ext.prefix = File name prefix for output files.

It would be very helpful to have some top level documentation to explain how to pass those arguments into their respective programs. For example, when discussing SortMeRNA, it would be nice to have some direction on how to pass arguments like:
--no-best or --idx-dir
to it via those variables. The same is true for STAR, which offers additional options when combined with Salmon, but not RSEM. While program defaults often work, they are not ideal, and the ability to configure a pipeline at the top level seems better than making changes deep down in the module config files.

[MatthiasZepper]

The desired top-level documentation is available on the nf-core website, but not duplicated for each pipeline.

RSEM does not allow passing custom arguments to STAR, so there is nothing that can be done there.

Regarding the ext.args in configs, there are multiple perceptions and good arguments for and against it. Please see this comprehensive discussion for some more insight into the why and how. If you have suggestions, the Beyond DSL2 pull request is probably a good place to have a say.

[charlesdavid]

Hi @MatthiasZepper , thanks for the reply. Yes, I saw the info on the nf-core website for ext.args but what I am trying to understand (as I am not a developer / contributor) is the relation between the multiple levels of this ext. What are the priorities of the different levels and are there examples of use cases documented for args2 and args3 like there is for ext.args?
After looking over the discussion on this topic, it seems that some developers favor moving these directives into the parameter space, while others are concerned with the development overhead such changes will incur. In the meantime, could we 'users' of the pipelines get some clarity on how these ext args should be used along with some example use cases?

[MatthiasZepper]

There is no priority or level. Using ext.args is a convention for nf-core modules and is commonly used.

In about 1% of the modules, a second set of arguments is needed, e.g. because they are positional arguments or because the module comprises a second tool that requires ext.args of its own.

tar for example, has positional arguments before and after the archive file:

        tar \\
            -C $prefix \\
            -xavf \\
            $args \\
            $archive \\
            $args2

[pinin4fjords]

Closing this, since it's not a pipeline issue.