fix(modules): address awgymer review comments on PR #139 (strict nf-core compliance)

[an-altosian]

Summary

Addresses the latest round of CHANGES_REQUESTED review comments by @awgymer on #139 (2026-05-11 + 2026-05-15). Eliminates params.* reads from process bodies and aligns module-level config with the nf-core modules guidelines:

All non-mandatory command-line tool non-file arguments MUST be provided as a string via the \$task.ext.args variable.

What changed

Module bodies — collapse to \${args} consumption only

• SEGGER_CREATE_DATASET, SEGGER_TRAIN, SEGGER_PREDICT, PROSEG — module bodies no longer read params.* directly. CLI flags assembled in conf/modules.config via withName: blocks, using the canonical STARDIST pattern (!= null guards + .join(' ').trim()).
• Drops the non-compliant custom ext.<field> keys (ext.format, ext.devices) — only args, args2, args3, prefix, when are sanctioned per nf-core.
• Drops the body-side if (params.format in ['xenium']) validation block (relocated to validateInputParameters()).

modules/nf-core/xeniumranger/{import-segmentation,resegment} — back to upstream parity

The locally-patched copies that read params.expansion_distance / params.boundary_stain / params.interior_stain / params.dapi_filter / params.expansion_distance directly (the "big no-no" awgymer flagged) are now byte-identical to upstream nf-core/modules git_sha 39365e944e9. The two .patch files were emptied and removed; modules.json cleaned up. All four flags now flow through ext.args closures in conf/modules.config.

nextflow.config — drop redundant .intValue()

`task.memory.toGiga().intValue()` → `task.memory.toGiga()`. MemoryUnit.toGiga() already returns long; the no-op chain warns under strict syntax.

maxForks — replace silently-inert dynamic directive

maxForks params.restrict_concurrency ? 1 : 0 in two SEGGER modules has been dropped — Nextflow forbids dynamic maxForks, so the directive never actually took effect. Replaced with a config-load-time block in conf/modules.config:

```groovy
if (params.restrict_concurrency) {
process {
withName: SEGGER_CREATE_DATASET { maxForks = 1 }
withName: SEGGER_TRAIN { maxForks = 1 }
}
}
```

This is the nf-core-idiomatic pattern and actually takes effect.

Validation relocation

• nextflow_schema.json: added \"enum\": [\"xenium\", \"cosmx\", \"merscope\"] to the format param, broadened description (no longer proseg-only).
• validateInputParameters() (in subworkflows/local/utils_nfcore_spatialxe_pipeline/main.nf) gained a method-aware compatibility check: segger requires xenium; proseg accepts all three. format plumbed through PIPELINE_INITIALISATION take: and the main.nf call site.

Bonus fixes (gated by the same review pass)

• Version evals: replaced 7 broken python3 -c \"import X; print(X.__version__)\" patterns (in spatialdata/{write,meta,merge}, utility/{downscale_morphology,parquet_to_csv,resize_tif,upscale_mask}, xenium_patch/{divide,stitch}) with pip show X 2>/dev/null | sed -n 's/^Version: //p'. The import-based form crashes when the package is missing OR when it doesn't expose __version__ (the spatialdata case unblocked the local stub test suite).
• Ruff F401: dropped 3 unused imports (spatialdata in bin/spatialdata_merge.py + bin/spatialdata_write.py, zarr in bin/spatialdata_meta.py).

Comments resolved

Comment	Module/file	What
3245861758	segger/create_dataset	params + dynamic maxForks
3245857609	xeniumranger/import-segmentation	params in nf-core module
3245855348	xeniumranger/resegment	params in nf-core module
3245874088, 3245874347	nextflow.config	.toGiga().intValue() warning
3216295080, 3216300407, 3216300657	segger/train	params + dynamic maxForks
3216307528	spatialdata/write	params outside entry

Test plan

• nextflow config -profile docker . parses
• nextflow inspect main.nf -profile test,docker — process graph clean
• pre-commit run --all-files passes
• ruff check bin/ tests/ — clean (was 3 F401 errors before)
• nf-test tests/coordinate_mode.nf.test — passes (exercises PROSEG, XENIUMRANGER_IMPORT_SEGMENTATION, SPATIALDATA_*)
• nf-test tests/default.nf.test — passes
• nf-test tests/segfree_mode.nf.test — passes
• nf-test tests/image_mode.nf.test — passes (after version-eval fixes)
• nf-test tests/preview_mode.nf.test — passes (after version-eval fixes)
• Module-level nf-tests for baysor/proseg with real data — pre-existing failures on upstream/dev unrelated to this PR (verified by reverting and re-running)

Follow-up (not in this PR)

A handful of baysor/xenium_patch modules still use non-compliant task.ext.<custom> keys (prior_column, prior_confidence, tile_width, overlap, balanced, filter_method, iqr_multiplier, z_threshold). Same anti-pattern as what's addressed here. Worth a focused follow-up PR.

nf-core compliance receipts

• nf-core modules guidelines (ext.args mandatory)
• Nextflow process directives (maxForks cannot be dynamic)
• Reference impl: nf-core/cellpose main.nf, nf-core/bcftools/mpileup main.nf

[an-altosian]

Hi @awgymer — code changes addressing the review comments are landed, but CI is hitting a runner disk-pressure issue that I can't see a clean in-PR fix for. Would appreciate input on how this is solved elsewhere.

The problem

A few pipeline-level stub tests (coordinate_mode, image_mode, default) fail on shards with:

docker: failed to register layer:
  write /xeniumranger-xenium4.0/external/anaconda/lib/libcudnn_ops.so.9:
  no space left on device

It's not a single image — it's cumulative pulls during a pipeline-level stub test that fail to fit on the runner's docker volume.

The numbers

From the runs-on info table in CI logs:

	Value
Runner	4cpu-linux-x64, AMI runs-on-v2.2-ubuntu24-full-x64
Total disk	29 GB (single /dev/nvme0n1p1, no second volume)
OS + preinstalled tools	~17 GB
Free at task start	~12 GB

Heaviest containers this pipeline pulls (extracted sizes):

Container	Size	Why
quay.io/nf-core/xeniumranger:4.0	7.92 GB	10x Genomics ships xeniumranger as a monolith bundling full Anaconda + CUDA (cuDNN, cuBLAS)
community.wave.seqera.io/library/python_pip_cellpose:*	~5 GB	PyTorch + CUDA runtime
quay.io/khersameesh24/baysor:0.7.1	5.52 GB	Julia runtime + scientific libs
spatialdata-io	~2 GB
ghcr.io/dcjones/proseg:v3.1.0	0.79 GB

A single coordinate-mode pipeline stub test cumulatively pulls ~10.7 GB (untar + spatialdata + proseg + xeniumranger) which barely fits or doesn't. The image-mode test pulls ~21 GB cumulative (adds cellpose + baysor) which definitely doesn't fit.

These are extracted on top of the 17 GB OS overhead, so on a 29 GB single volume there's no room.

What I tried that didn't work

• disk=large → disk=xlarge: label appeared to be ignored by the runs-on config — runner still got the same 29 GB single volume.
• image=ubuntu24-noble-x64 (to swap the AMI for a slim variant with less preinstalled tooling): label not found in this org's runs-on config (failed to resolve image spec: image ubuntu24-noble-x64 not found in default images or repo config). I reverted.
• Aggressive cleanup of preinstalled tools (sudo rm -rf /usr/share/dotnet /usr/local/lib/android /opt/ghc /opt/hostedtoolcache/CodeQL ...): freed ~3-4 GB — enough for the coordinate-mode tests but not for image-mode.
• max_shards: 12 → 24 (one test per shard so module-level baysor and the pipeline test don't share /var/lib/docker): reduced failure count but didn't fix the single-test cumulative problem.

What I'd like to know

How are other nf-core pipelines with similarly heavy containers solving this? I checked:

• nf-core/sopa uses similar 3-4 GB cellpose images and is currently also failing CI (but with a different script-level error).
• nf-core/spatialvi passes — but only uses lightweight scanpy/squidpy/harmonypy containers, no GPU-bundled tools.
• nf-core/sarek, rnaseq, methylseq — all use biocontainers (50-500 MB each), no cumulative-pull pressure.

Options I can see but want a steer on:

1. Bigger disk on the runner pool — does nf-core's runs-on config support an image= or disk= label that actually grows the root volume? Or a runner type with more storage?
2. Pre-pulled / cached AMI — a custom runs-on AMI with xeniumranger:4.0, cellpose:*, baysor:0.7.1 already extracted in /var/lib/docker, so the test only pulls deltas?
3. Slim the upstream containers — split xeniumranger:4.0 into 4.0-cpu (no CUDA) and 4.0-gpu; ship cellpose-cpu for stub tests. This is an nf-core/modules change, not this PR.
4. Skip pipeline-level stubs on PR CI and only run them on master/release — would reduce CI value but eliminate the wall.
5. Something else the community already does that I'm missing.

If there's a documented pattern for handling this, I'd love a pointer. If not — and this is genuinely an open problem — I'll leave the failing shards flagged and move on, since the actual code in this PR is verified to pass locally end-to-end.

Local verification: nf-test test --profile=+docker --ci --changed-since upstream/dev → 21/21 passing in 1131s on a host with adequate /var/lib/docker headroom. Same command, same containers, same image SHAs — just on a machine that's not 29 GB-limited.

Thanks for any pointers!

[awgymer]

The easiest solution here. Use volume (not the old disk=large") syntax to bump the volume size

https://runs-on.com/configuration/job-labels/#volume

[an-altosian]

Hi @awgymer , do you think this PR can address the second round of comments?

[heylf]

LGTM