Containers and Computational Environments
Code runs the same only when its surroundings are the same; capturing the whole environment makes a result portable and durable.
The Environment Is Part of the Result
A computation depends not only on its source code but on everything around it: the compiler, the numerical libraries, the operating system, and the versions of each. Change any of these and the result may shift or fail to run. Reproducibility therefore requires capturing the environment, not just the code.
Ways to Capture It
- Dependency manifests that pin exact library versions.
- Virtual environments that isolate one project's packages from another's.
- Containers that package the code with its entire user-space environment as one image.
- Environment records that log the resolved versions actually used at run time.
What Containers Do and Do Not Solve
A container bundles an application with its libraries and system tools into a portable image that runs the same across machines. It solves the problem of missing or mismatched dependencies. It does not by itself make results bitwise identical across different hardware, because the processor and its floating-point behavior lie below the container boundary.
Durability Over Time
Environments decay: package repositories change, links rot, and a project that ran last year may not build today. Archiving a container image or a fully pinned manifest preserves the ability to rebuild and rerun long after the original machine is gone, which is what turns a one-time result into a durable one.
At Kronos
Reproduction packages for frozen results record the environment alongside the code and inputs, so an independent party can rebuild a matching setup and regenerate a number within the stated tolerance. Capturing the environment is treated as part of capturing the result, not an afterthought.