ADR: module parameters

[pditommaso]

Summary

Introduces ADR for module parameters specification, defining how parameters can be declared and configured in Nextflow modules.

Key aspects covered:

• Parameter specification in meta.yaml for documentation, validation, and IDE support
• Two options for script-level parameter definition:
  • Option A: Process-level params: block (scoped to process)
  • Option B: Module-level params {} block (accessible in workflow)
• Parameter semantics: typing, defaults, immutability
• Configuration and CLI override mechanisms
• Comparison with legacy ext.args approach

Related

• Module System ADR: adr/20251114-module-system.md

---

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for nextflow-docs-staging canceled.

Name	Link
🔨 Latest commit	a658766
🔍 Latest deploy log	https://app.netlify.com/projects/nextflow-docs-staging/deploys/697a0f3e0f50720007805921

[bentsherman]

One approach we are looking at with records is to refactor the ext settings as fields in the input record.

For example, nf-core/methylseq uses the bedtools/intersect module, which has several ext settings:

    def args = task.ext.args ?: ''
    def prefix = task.ext.prefix ?: "${meta.id}"
    extension = task.ext.suffix ?: "${intervals1.extension}"

The methylseq pipeline customizes these settings further:

process {
    withName: BEDTOOLS_INTERSECT {
        ext.args   = ''
        ext.prefix = { "${intervals1.baseName}" }
        ext.suffix = 'targeted.bedGraph'
    }
}

With records, we could provide these ext settings in the input record:

// process definition
input:
(
    id: String,
    intervals1: Path,
    intervals2: Path,
    args: String,
    prefix: String,
    suffix: String
): Record

Then define them in an extra map operator

// workflow logic
ch_intersect_inputs = ch_inputs
    .map { r -> record(
        id: r.id, 
        intervals1: r.bedgraph,
        args: '',
        prefix: r.bedgraph.baseName,
        suffix: 'targeted.bedGraph'
    ) }

ch_bedgraph_filtered = BEDTOOLS_INTERSECT( ch_intersect_inputs, intervals2: target_regions )

If this works out, we might not need module params at all. Especially since module params are constants but these ext settings often need to be dynamic (like prefix in the above example). But we'll see.

[pditommaso]

With records, we could provide these ext settings in the input record

This aligns with the point that "mutable" parameters should be managed as proper inputs. It makes sense to me