It is already possible to run a setup script before the actual job, using the pre_job_script setting. When used in combination with a Singularity container, it is executed outside of the container. Depending on the use case, this can be desired, so that should not change. However, there might be use cases where it would better be inside the container.
Maybe as a solution that somewhat covers both: Add an option env_setup_script (name open to discussion) in the singularity section. If set, this script is sourced (not executed) within the container before running the main script.
This could then be used in a flexible way to activate any kind of virtual environment and do other stuff as needed.
It's a bit the question if this is really needed, though, as it could already be achieved via a runscript inside the container. The additional setting would only be useful, if there are use cases where the setup script changes frequently or the same container might be used with different setup scripts.
Extracted from #68
It is already possible to run a setup script before the actual job, using the
pre_job_scriptsetting. When used in combination with a Singularity container, it is executed outside of the container. Depending on the use case, this can be desired, so that should not change. However, there might be use cases where it would better be inside the container.Maybe as a solution that somewhat covers both: Add an option
env_setup_script(name open to discussion) in the singularity section. If set, this script is sourced (not executed) within the container before running the main script. This could then be used in a flexible way to activate any kind of virtual environment and do other stuff as needed.It's a bit the question if this is really needed, though, as it could already be achieved via a runscript inside the container. The additional setting would only be useful, if there are use cases where the setup script changes frequently or the same container might be used with different setup scripts.