Module version pinning

Ask for help
1

ADR v2.7 removed the modules {} config block (originally FR-020), with the rationale that inferring versions from installed meta.yml files reduces configuration burden.

For organizations sharing modules across many projects, the config declaration is actually the desired behavior: it keeps the registry as the single source of truth and avoids committing module source into every project repo.

Our use case: 30+ workflow projects share a common set of modules from a private registry. Under the current model, every project either commits modules/ to Git (30 copies of the same source) or needs a pre-run install script to fetch them.

What we’d want instead:

// .gitignore
modules/

// nextflow.config
modules {
‘myorg/alignment’ = ‘1.2.3’ // pinned for production
‘myorg/qc’ = ‘latest’ // latest for development
}

Nextflow fetches from the registry on run if the module is absent or the version doesn’t match. No modules/ in Git, no manual install step.

Is this planned, or is there a recommended pattern for the registry-as-single-source-of-truth use case?

2

The removal in the ADR doesn’t mean we will never do it, just that we didn’t do it in that iteration

The expectation remains that modules should be installed and saved in source control, for a pipeline project. You can use nextflow module list -o json to “materialize” a list of module versions if you need it

We will likely expand on this in the future, but we are still evaluating a few different approaches