Related but distinct: #329 (configurable placement of the containers subdataset). This issue is about how the image path is resolved within the container dataset, not where the subdataset lives.
Problem
babs init assumes a fixed image path inside the container subdataset — the datalad-containers default .datalad/environments/<name>/image. That works for a container dataset created with datalad containers-add <name> --url <sif>, but not for a container dataset that registers its image elsewhere.
In particular, ReproNim/containers stores images at a non-default location (e.g. under images/<collection>/...) and registers them through datalad-containers with a custom call-fmt/image in .datalad/config. Pointing babs init at a ReproNim/containers dataset (the recommended way to get pinned, archived BIDS-App SIFs) therefore fails to locate the image, because babs looks at the assumed default path rather than the registered one.
Why this matters now
This path resolution is currently handled in a working branch that is being abandoned, so the capability needs a home in the babs codepath that survives. A downstream automation already works around it externally — resolving the image with datalad containers-list -d <analysis> | grep <name> before datalad get — which shows the fix is small and that babs has all it needs to do this itself.
Proposal
Have babs resolve the container image path from the datalad-containers registration rather than assuming .datalad/environments/<name>/image:
- Read the registered image path for
<container_name> from the container subdataset (via datalad containers-list, or the datalad.containers.<name>.image config), and use that wherever babs currently hardcodes the path (the babs init scaffolding + the participant_job.sh container-link block).
- Fall back to the current default when no registration is found, so existing projects are unaffected.
This makes babs init work with any datalad-containers dataset — including ReproNim/containers — without per-dataset assumptions.
Notes
Related but distinct: #329 (configurable placement of the containers subdataset). This issue is about how the image path is resolved within the container dataset, not where the subdataset lives.
Problem
babs initassumes a fixed image path inside the container subdataset — the datalad-containers default.datalad/environments/<name>/image. That works for a container dataset created withdatalad containers-add <name> --url <sif>, but not for a container dataset that registers its image elsewhere.In particular,
ReproNim/containersstores images at a non-default location (e.g. underimages/<collection>/...) and registers them through datalad-containers with a customcall-fmt/imagein.datalad/config. Pointingbabs initat a ReproNim/containers dataset (the recommended way to get pinned, archived BIDS-App SIFs) therefore fails to locate the image, because babs looks at the assumed default path rather than the registered one.Why this matters now
This path resolution is currently handled in a working branch that is being abandoned, so the capability needs a home in the babs codepath that survives. A downstream automation already works around it externally — resolving the image with
datalad containers-list -d <analysis> | grep <name>beforedatalad get— which shows the fix is small and that babs has all it needs to do this itself.Proposal
Have babs resolve the container image path from the datalad-containers registration rather than assuming
.datalad/environments/<name>/image:<container_name>from the container subdataset (viadatalad containers-list, or thedatalad.containers.<name>.imageconfig), and use that wherever babs currently hardcodes the path (thebabs initscaffolding + theparticipant_job.shcontainer-link block).This makes
babs initwork with any datalad-containers dataset — including ReproNim/containers — without per-dataset assumptions.Notes
code/containers(the ReproNim-recommended location); this lets babs find the image inside it regardless of layout. Both are wanted for first-class ReproNim/containers support.