We often have to specify runOptions for the docker scope for nf-core modules or pipelines due to tools writing for example to $HOME during their runtime without an option to disable this (model downloading, log writing or other things).
As an example option we require for one nf-core module, we have to mount home via:
docker {
runOptions = '-v $HOME:$HOME'
}
How can we ensure that these runOptions are passed to Wave properly or can we directly provide WAVE options to ensure, that Wave will also handle these mount requirements properly? Is there something like a wave.runOptions setting?
Wave builds containers, Docker is one option to run them. Your docker.runOptions example means ‘mount home directory when running container’, which happens while running the container. So this solution should work absolutely fine for your example.
You may also want to look at process.containerOptions which is a per-process equivalent of docker.runOptions.
When running a process with Docker, it works kinda like this:
docker run ${docker.runOptions} ${process.containerOptions} ${process.container} .command.sh
We actually managed now to set an ENV variable at image creation, to write models from the tool into a different folder than $HOME, removing the requirement to mount $HOME when running the container.
So for the future, I am still not sure exactly which Docker options will pass over to Wave when run with Fusion without issues and which ones might be overwritten. Is the ENTRYPOINT of the container just a special case because Fusion needs to be the entrypoint of the container?
ENTRYPOINT is a property of the container, it runs automatically when you start the container. This is slightly different to something applied to a container when you run it, which is only applied to that specific instance. When I am building a docker image, I try to avoid using ENTRYPOINT because it turns the docker container into a single use tool and a user should be able to set this for their purposes, such as starting the Fusion binary before doing some bioinformatics .
So yes, ENTRYPOINT is a special case for Fusion but also Nextflow in general. And everything else. Avoid it, if someone knows what they’re doing ENTRYPOINT can be powerful but for most people it’s better to leave it alone and just apply it at runtime.
I’d be careful with this, an ENV variable isn’t immutable and can be modified at runtime. Still, if you wanted to set $HOME for a process you can do:
I fully agree with your ENTRYPOINT comments and we never set an ENTRYPOINT when building our own containers. The entrypoint problem was for a container made by the tool authors that defined an ENTRYPOINT.
.