Open charlesdavid opened 4 months ago
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.
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?
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
Description of feature
Given that the modules.config file contains the following:
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.