nextflow-io / nextflow

A DSL for data-driven computational pipelines
http://nextflow.io
Apache License 2.0
2.76k stars 630 forks source link

singularity.cacheDir does not work properly with containers that have ':' in the filename #5324

Open stevekm opened 1 month ago

stevekm commented 1 month ago

Bug report

with my nextflow.config like this;


singularity {
    enabled = true
    autoMounts = true
    cacheDir = "/fsx/home/tools/containers"
}

process {
    executor = 'slurm'
    container = 'nextflow_bash:latest.sif'

    withName: DebugScript {
        container = 'pytorch_pytorch:latest.sif'
    }
}

The required containers exist as such;

$ ll /fsx/home/tools/containers/nextflow_bash:latest.sif
-rw-r--r-- 1 username mygroup 29M Sep 23 16:44 /fsx/home/tools/containers/nextflow_bash:latest.sif

$ ll /fsx/home/tools/containers/pytorch_pytorch:latest.sif
-rw-r--r-- 1 username mygroup 3.5G Sep 23 17:39 /fsx/home/tools/containers/pytorch_pytorch:latest.sif

However, when you run Nextflow, it breaks with an error such as

Pulling Singularity image docker://nextflow_bash:latest.sif [cache /fsx/home/tools/containers/nextflow_bash-latest.sif]
Pulling Singularity image docker://pytorch_pytorch:latest.sif [cache /fsx/home/tools/containers/pytorch_pytorch-latest.sif]
ERROR ~ Error executing process > 'DebugScript'

Caused by:
  Failed to pull singularity image
    command: singularity pull  --name pytorch_pytorch-latest.sif.pulling.1727127729010 docker://pytorch_pytorch:latest.sif > /dev/null
    status : 255

As you can see from the log and error messages, the cacheDir directive is not correctly detecting the files nextflow_bash:latest.sif and pytorch_pytorch:latest.sif, and is instead looking for the files nextflow_bash-latest.sif and pytorch_pytorch-latest.sif which do not exist.

Is this a bug? This behavior is not described in the docs ( https://www.nextflow.io/docs/latest/config.html#scope-singularity ), and I have not encountered this issue in the past with filenames that lack ':'. Considering that our files are on a soon-to-be S3 backed storage system, having to constantly rename the .sif files to match this unexpected different filename is a little bothersome.  

Environment

bentsherman commented 1 month ago

Looks like it is intentional:

https://github.com/nextflow-io/nextflow/blob/33fab52d0c3080277a11090bad9d9f84932b21c6/modules/nextflow/src/main/groovy/nextflow/container/SingularityCache.groovy#L76-L101

stevekm commented 1 month ago

Ok. Any ideas where this convention originated? Is this a Singularity convention or something that was implemented independently on Nextflow-side?

We are building our .sif files via a scripted method, so I will have to go back and update my script to use this naming scheme instead.. and re-name all of our existing .sif files, I guess.

Not sure if there's any room for flexibility or customization for how nextflow should expect the .sif filename to look