Isolation

The goal of Isolation is that any computational unit can be integrated into a study regardless of its programming language, operating system, and dependencies, without interfering with any other unit. Each collaborator can then contribute and develop units independently, in an environment that belongs to that unit alone.

The mechanism is encapsulation of each unit's compute environment, through package management, containerisation, or both. How far you need to go depends on the study. Four questions help you find the right level.

What software ecosystem does each unit require? Which programming language, operating system, and dependencies? If everything a unit needs is available through a package manager like conda, Iso1 is enough. If a unit depends on a complex build system, legacy software, or packages that conda does not carry, you need a container, which is Iso2.

Where will each unit run? A collaborator's laptop, an HPC cluster, or cloud? Laptops and cloud are fine with conda environments or Docker images. HPC clusters usually forbid Docker, so a unit headed there needs the Apptainer route described in Iso3.

What level of reproducibility is required? Per-OS, per-architecture lock files (Iso1) give you numerically equivalent results across the platforms your collaborators use. If you need a fully controlled environment that also pins system libraries, containers (Iso2) are the answer.

How heterogeneous is the study, and how much change do you expect? The more operating systems, CPU architectures, and collaborators involved, and the more often environments change, the sooner maintaining lock files and images by hand stops scaling. That is when you automate the whole thing in CI, which is Iso4.

A sensible default: start every unit with a conda environment and lock files (Iso1), containerise the units that need it (Iso2), convert to Apptainer when HPC enters the picture (Iso3), and put lock and image maintenance into CI as soon as more than one person depends on them (Iso4).