Wave as hosted by Seqera has supported multi-arch singularity/apptainer builds through oras for a while (which is essentially the two different architectures built separately and relying on oras smarts to deliver the correct thing). This is now also supported by the latest support by the latest wave-cli (from the main wave repository now). This has been working for Given this, I think

nf-core modules container create

should be updated to switch to provide these links by default in the

main.yml

. I'd be happy hearing why I'm wrong before I start doing things :) (My long term goal is having sensible support of multi-architecture setups, such as NAISS have now with arrhenius with arm64 GPU machines and amd64 CPUs - I have at least not found a workable way to deal with that with the current setup.)

You mean use

oras

instead of

https

by default basically?

Yes (and promote the multi-arch references rather than amd64).

The logic for why we have this currently is here: nf-co.re/blog/2024/seqera-containers-part-2#…

Using

oras

has some advantages:

• Singularity handles pulls in the process task, rather than in the Nextflow head job

◦ This means less resource usage on the head node, and more parallelisation

• Singularity can use authentication to pull from private registries (see Singularity docs for more information).

However, there are some downsides:

• Shared cache Nextflow options such as

$NXF_SINGULARITY_CACHEDIR

and

$NXF_SINGULARITY_LIBRARYDIR

are not used

• Singularity must be installed when downloading images for offline use

•

oras://

is only supported by recent versions of Singularity / Apptainer

As such, we will continue to use

https

downloads for Singularity

SIF

images for now. However, we will start to provide new

-profile singularity_oras

profiles for anyone who would prefer to fetch images using the newer

oras

protocol.

Yes, and the caching isn't true today either. And I haven't tested it, and don't know if it would be too much of an addition for tools, but there are "official" oras bindings for python that seem to be easy enough to integrate.

Shared cache Nextflow options such as

$NXF_SINGULARITY_CACHEDIR

and

$NXF_SINGULARITY_LIBRARYDIR

are not used

This isn't true you mean?

At least for me:

pontus@lalage:~/Utveckling/nextflow-test/y$ rm -rf work/singularity/
pontus@lalage:~/Utveckling/nextflow-test/y$ nextflow run <http://a.nf|a.nf>
Nextflow 26.10.3 is available - Please consider updating your version to it

 N E X T F L O W   ~  version 25.10.2

Launching `<http://a.nf|a.nf>` [happy_chandrasekhar] DSL2 - revision: 4f221c4052

executor >  local (1)
[74/35abd1] process > AB [100%] 1 of 1 ✔
Pulling Singularity image <oras://community.wave.seqera.io/library/bamtools:bamtools-2.5.2--9dc13f81c34a48b0> [cache /home/pontus/Utveckling/nextflow-test/y/work/singularity/community.wave.seqera.io-library-bamtools-bamtools-2.5.2--9dc13f81c34a48b0.img]
test_label
2
WARN: Singularity cache directory has not been defined -- Remote image will be stored in the path: /home/pontus/Utveckling/nextflow-test/y/work/singularity -- Use the environment variable NXF_SINGULARITY_CACHEDIR to specify a different location

pontus@lalage:~/Utveckling/nextflow-test/y$ ls work/singularity/
community.wave.seqera.io-library-bamtools-bamtools-2.5.2--9dc13f81c34a48b0.img
pontus@lalage:~/Utveckling/nextflow-test/y$

"architecture coded" - what does this mean? Put x86 in the filename or something?

Basically, yes. Probably clearer with an example and since we have arrhenius: • I don't want to change things about how nextflow works if that can be avoided • I want to support runs where CPU codes run on CPU nodes (amd64) • I want those same runs to be able to support GPU codes (that would need to run on arm64) • Nextflow will download containers at start, I want these to be suitable (respect process arch setting) • I believe it's also useful for these situation if it's visible if something has an explicit arch • I can also imagine wanting to use the same container image for different subtools where one would run on GPUs (arch

linux/arm64

here) and one on CPU (

linux/amd64

), and that shouldn't break with errors users don't understand.

I think

nf-core download

already renames stuff and makes a config file that points to the downloaded files.. 🤔

Possible, I understand

nf-core download

needs to continue working but I'm not terribly concerned with it. I guess one can make the case for reproducibility if e.g. the nf-core organisation should disappear along with all its repos, but I really don't want everybody to have a bunch of different copies of each pipeline.