Charliecloud is an alternative container engine that runs completely in user space.
Nextflow supports it since v20.12.0-edge, thus it would also be a useful addition to nf-core, as some research institutions do not allow singularity because of strict security policies.
My proposal would be to add conf/charliecloud.config with the following content to the template:
charliecloud {
enabled = true
}
manifest {
nextflowVersion = '>=20.12.0-edge'
}
env {
PATH = "/opt/conda/bin:/opt/conda/envs/{{ cookiecutter.name_noslash }}-{{ cookiecutter.version }}/bin:$PATH"
}
Note that the env part is necessary because Charliecloud does not honor ENV layers in Docker containers, meaning the path to the conda env within the docker container has to be passed to the container explicitly.
This should work for most pipelines. Unfortunately, for pipelines that have multiple environments, the PATH would need to be appended manually in the respective pipeline repository.
Once all nf-core pipelines use biocontainers this can be simplified to:
env {
PATH = "/opt/conda/bin"
}
Sounds all good to me. Multiple environments are normally not an issue I guess. Most people will not be affected by this, though it might make sense to also provide CI tests for running with CharlieCloud then at some point. Something we should also do with podman, which is supported since a while now too...
Multiple environments = meaning in the same docker image or per process having different ones?
Multiple environments = meaning in the same docker image or per process having different ones?
Both actually, we need to pass every location that contains dependencies to the container.
AFAIK pipelines with multiple environment.ymls have multiple Dockerfiles as well (one per environment). nf-core Sarek for example
For biocontainers, it is much easier because their environment is always installed to /opt/conda/bin without any names or version tags.
We do have multiple Dockerfile for specific processes in Sarek, but they do contain annotation database, which we can't get in conda, so path should still be the same actually.
But that does look interesting.
Thanks for the clarification @phue :-)
We do have multiple Dockerfile for specific processes in Sarek, but they do contain annotation database, which we can't get in conda, so path should still be the same actually.
But that does look interesting.
But aren't there specific conda environments in the containers for snpeff and vep?
It seems that they have /opt/conda/envs/nf-core-sarek-snpeff-2.6.1/bin and /opt/conda/envs/nf-core-sarek-vep-2.6.1/bin as opposed to /opt/conda/envs/nf-core-sarek-2.6.1/bin
Therefore, running Sarek with Charliecloud would require this config:
charliecloud {
enabled = true
}
manifest {
nextflowVersion = '>=20.12.0-edge'
}
env {
PATH = "/opt/conda/envs/nf-core-sarek-2.6.1/bin:/opt/conda/envs/nf-core-sarek-snpeff-2.6.1/bin:/opt/conda/envs/nf-core-sarek-vep-2.6.1/bin:$PATH"
}
Most helpful comment
Both actually, we need to pass every location that contains dependencies to the container.
AFAIK pipelines with multiple
environment.ymls have multipleDockerfiles as well (one per environment). nf-core Sarek for exampleFor biocontainers, it is much easier because their environment is always installed to
/opt/conda/binwithout any names or version tags.