New RFC: Allow ext.suffix as an official ext. value allowed for use in nf-core/modules

[SPPearce]

Have you read the RFC docs?

• Yes, I have read and understood the RFC docs

Summary

I suggest that we officially allow the use of ext.suffix inside nf-core/modules, updating the documentation accordingly.

Champion

No response

Background & Motivation

Following the discussion in #65 about using a ext. value for memory management, I took a look at what other ext. values we have in modules.

Currently we have as 'official':

ext.args
ext.args{2..5}
ext.prefix
ext.singularity_pull_docker_container
ext.when

We currently have ~25 modules that use ext.suffix as well as ext.prefix.
For example with a tool that takes as input both bam and cram files, and can generate either bam and cram files depending on the given file name, it is reasonable to assume you want the output file to be the same type most of the time, but allow for changing it:

    input:
    tuple val(meta), path(bam)

    script:
    def prefix = task.ext.prefix    ?: "${meta.id}"
    def suffix = task.ext.suffix    ?: "${bam.getExtension()}"
    """
    gatk AddOrReplaceReadGroups \\
        --INPUT ${bam} \\
        --OUTPUT ${prefix}.${suffix}
   """

Using a value channel for this is pretty clunky, particularly when there is a default, and this is just a counterpart to ext.prefix.

Note there are 15 modules using other wildcard ext. options, that should really be tidied up at some point.

Goals

• Formalise what is being done in a number of modules
• Update the guidelines to make it clear this is an acceptable use

Non-Goals

• Don't allow proliferation of lots of additional other ext. fields

[nf-core-bot]

RFC approval status: 🕐 Pending

RFC has approvals from 2/7 required @core-team quorum.

Review Status	Core Team members
✅ Approved	@maxulysse, @nvnieuwk
🕐 Pending	@ewels, @mribeirodantas, @mashehu, @JoseEspinosa, @mirpedrol, @FriederikeHanssen, @kenibrewer, @jfy133, @edmundmiller, @sateeshperi, @FranBonath, @christopher-hakkaart

[maxulysse]

/approve

[nvnieuwk]

/approve

[nvnieuwk]

Although, we could also make this an input of the module, but that's a whole other discussion

[SPPearce]

Although, we could also make this an input of the module, but that's a whole other discussion

Yes, we can, and some modules do.

[maxulysse]

cf nf-core/modules#8914 as a potential good example

[mahesh-panchal]

In my opinion, ext.suffix doesn't need the flexibility ext.prefix does. The prefix is often based on the name so might need dynamic configuration by the user. Suffix though should be an enumeration/fixed set of values and can therefore be controlled by a parameter/input.

Are there cases where this is not true?

[prototaxites]

I think generic modules like GAWK benefit from the flexibility to specify any desired suffix, given that awk is a processing tool that theoretically can write more types of output file than could easily be enumerated: https://github.com/nf-core/modules/blob/master/modules/nf-core/gawk/main.nf

[mahesh-panchal]

I agree that it should be flexible, but does it need to be flexible in a dynamic way that an input parameter cannot handle?

[prototaxites]

No, it could certainly be an input value - but it is a case that an enum/fixed set of values would IMO be inappropriate.

[maxulysse]

Example made:
nf-core/modules#8947

[nf-core-bot]

Approval status: 🕐 Pending

RFC has approvals from 2/7 required @nf-core/core quorum.

Review Status	Core Team members
✅ Approved	@maxulysse, @nvnieuwk
❌ Rejected	@jfy133, @JoseEspinosa
🕐 Pending	@ewels, @mribeirodantas, @mashehu, @mirpedrol, @FriederikeHanssen, @kenibrewer, @edmundmiller, @sateeshperi, @FranBonath, @christopher-hakkaart