Inspired by @just-meng's workaround in
To make it flexible but specific, I think we should allow for some datalad config like datalad.repronim-containers.singularity-opts or alike, which then https://github.com/ReproNim/containers/blob/master/scripts/singularity_cmd would query and potentially add to singularity invocations. Alternative would be to get closer to @just-meng workaround and override the overall datalad.containers.NAME.cmdexec but IMHO it is undesired since
- would require change of current
.datalad/config and some invocations could be already "frozen" (copied) into corresponding super-datasets
- variable would then ideally should be repronim and containers and run specific, not just
bindpaths, since easy to collide
so, by centralizing to singularity_cmd we concentrate where applicable and universally across all containers. Per container specs could still be changed within .datalad/config .
Inspired by @just-meng's workaround in
To make it flexible but specific, I think we should allow for some datalad config like
datalad.repronim-containers.singularity-optsor alike, which then https://github.com/ReproNim/containers/blob/master/scripts/singularity_cmd would query and potentially add to singularity invocations. Alternative would be to get closer to @just-meng workaround and override the overalldatalad.containers.NAME.cmdexecbut IMHO it is undesired since.datalad/configand some invocations could be already "frozen" (copied) into corresponding super-datasetsbindpaths, since easy to collideso, by centralizing to singularity_cmd we concentrate where applicable and universally across all containers. Per container specs could still be changed within .datalad/config .