Are there guidelines for tools that take two sets of args (

ext.args

+

ext.args2

) and the order they should be given?

script:
    def args   = task.ext.args ?: ''  // fgbio tool options
    def args2  = task.ext.args2 ?: '' // fgbio common options
    prefix = task.ext.prefix ?: "${meta.id}_zipped"
    def mem_gb = 8
    if (!task.memory) {
        <http://log.info|log.info> '[fgbio ZipperBams] Available memory not known - defaulting to 8GB. Specify process memory requirements to change this.'
    } else if (mem_gb > task.memory.giga) {
        if (task.memory.giga < 2) {
            mem_gb = 1
        } else {
            mem_gb = task.memory.giga - 1
        }
    }

    if ("${unmapped_bam}" == "${prefix}.bam") error "Input and output names are the same, use \"task.ext.prefix\" to disambiguate!"
    if ("${mapped_bam}" == "${prefix}.bam") error "Input and output names are the same, use \"task.ext.prefix\" to disambiguate!"
    if (!args2.contains('--compression ')) {
        args2 += " --compression 0"
    }
    """
    fgbio -Xmx${mem_gb}g \\
        ${args2} \\
        --async-io=true \\
        ZipperBams \\
        --unmapped ${unmapped_bam} \\
        --input ${mapped_bam} \\
        --ref ${fasta} \\
        ${args} \\
        --output ${prefix}.bam
    """

I'm removing the

ext.compression

field in favour of an ext.args2. For minimal disruption,

ext.args

should be the tool options, but if we go by order, it would be the common options ( and args must come in the order

fgbio <common options> Tool <tool options>

@Francesco Lescai Is there a reason some of these flags are hard-coded?

you’re asking me to remember something done 2-3 years ago when some of the things we have sort of standardise now weren’t as defined 😅 on top of my head I believe there were many potential arguments to this tool and we wanted to standardise the goal of this module. an issue for debate has always been documentation: if you used

ext.args

for anything which is not input and output of the tool, some tools could do really anything and it’s difficult to control whether the user sets the right things in the config file of a specific pipeline employing that module, unless you ship also a template config (this has also been for years an argument of conversation if I remember). bottom line: don’t have an answer which can offer a potential solution 😛

Associated PR https://github.com/nf-core/modules/pull/10691