How to Write and Share Replicable Research Code

press S key to access slide notes, F : back to presentation view
log EDUC University of Rennes logo Jaume Primero universitat logo

what is actualy doing Open Science

Open Science is about :

sharing things by making them findable and accessible
adapting them to existing artifacts (interoperability)
preparing and documenting them so they could be reused (reusability)
opening them to contribution (specific for source code)

a source code is static…

…but the environment which it’s designed for is moving quickly…

…creating code is like building house of cards grounded on sand

“In modern software there are always dependencies. No one spells out the ones and zeros for the machine by hand, so we write towers of software built on towers of software built on towers of software. And these dependencies change”

📓 Fobbe (2024)

a more comprehensive way of doing things would be to make a complete snapshot of all the needed Python dependencies along with the system dependencies. this new config file, known as a Dockerfile, will make it possible to run an image of the script based on a complete environment within a container. Everyone can download the container and run it with docker installed on their machine. Or if the dockerfile only was shared (because a docker image is heavy), you might use it to build your own image of the code.

below are described the main parts of a Dockerfile:

you will need an OS image to run this code ; Ubuntu is two heavy, Alpine weight much less and will drastically reduce the compilation time. So once an Alpine OS is pulled, you will add the different layers : first the compiler for Haskell (line 2) then Python itself, and the pip package manager(line 3) finally you will ask the system to install the python dependencies called by the script (line 4) this config file is oversimplified to show how it works basically I this machinery is quite complex and requires a deep understanding of how Docker builds images. besides the image pulled itself is not reproducible. Outputs may vary on the long run. Docker is better to deploy a code on different machines at the same time than to build reproducible source code on a long period of time. There must be something simpler to solve the reproducibility challenge

when older versions of dependencies disappear

they might disappear from the language repositories (Pypi)
they can also disappear from the forges where they were stored
and new versions appear to be non compatible with other components (such as in our example)

Guix as a package manager offers solutions to those prooblems

Guix provides fully consistent computational environments in only two config files (manifest and channels)
these config files track all packages used with their own version and the dependencies to these packages
if a dependency cannot be found online anymore, a fall-back system links missing components to their archived counterparts in Software Heritage (1)
Guix can be used on Windows through WSL2
guix allows to run on a single computer a script with different versions of the same package without any conflict
for non-guix users, guix easily packages the software into a Docker container (2)

📓 Courtès et al. (2024)
📓 Tournier (2024)

example

Guix users need only two config files to reproduce the environment or a past experience :

manifest.scm : enumerate all the dependencies (system and software)
channels.scm : defines their exact version

guix time-machine --channels=channels.scm -- shell --manifest=manifest.scm \
-- Rscript myscript.R

Thanks to Guix maintainers, writing code feels a bit less like “writing in the sand”

references

Courtès, L., Sample, T., Tournier, S., & Zacchiroli, S. (2024, June). Source code archiving to the rescue of reproducible deployment. Proceedings of the 2024 ACM Conference on Reproducibility and Replicability, Proceedings of the 2024 ACM Conference on Reproducibility and Replicability. https://doi.org/10.1145/3641525.3663622

Fobbe, S. (2024). The Limits of Reproducibility with Rocker Docker Images for R (posts). https://seanfobbe.com/posts/2024-12-16_reproducibility-limits-rocker-docker-images-r/.

Tournier, S. (2024, December). (Re)déploiement de conteneurs et machines virtuelles avec guix. JRES (Journées Réseaux de l’enseignement Et de La Recherche ) 2024.