# Guix: From Transparent and Verifiable to Long-Term Reproducible Research?

Simon Tournier

► To cite this version:

Simon Tournier. Guix: From Transparent and Verifiable to Long-Term Reproducible Research?. DebConf25, IRISA, Jul 2025, Brest, France. pp.5. hal-05334487

HAL Id: hal-05334487

https://hal.science/hal-05334487v1

Submitted on 28 Oct 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Guix: From Transparent and Verifiable to Long-Term Reproducible Research?

Simon Tournier

Université Paris Cité

Paris, France

Email: simon.tournier@inserm.fr

ORCID: 0000-0002-2639-818X

***Abstract***—Software plays a central role in scientific production since most of research results are the outcome of computational processes. Hence, the ability to verify research results and to experiment with methodologies, two core tenets of the scientific methods, require reproducible software deployment.

Guix is a software deployment tool that supports reproducible software deployment. Its features include user specific package installation, transactional upgrades and rollbacks, packing containers, virtual machine instantiation. And Debian and Guix can coexist concurrently on the same running system.

Here, we focus on two features of Guix. When scientific practitioners experiment with methodologies, they need the ability to replace one or more dependencies in the whole set of the dependencies; changing the version, configuration or compilation options, compiler, etc. Guix easily allows to create user customized packages and computational environment variants.

When scientific practitioners verify research results, they need all the source code and how this source code is transformed into binary. This transformation is captured by the Guix revision (snapshot) and easily available via the command *guix time-machine*. The source code availability is backed up by Software Heritage: a long term, non-profit, multistakeholder initiative with the ambitious goal to collect, preserve and share all source code publicly available, and to our knowledge Software Heritage is the largest publicly available archive of source code.

Guix is the first free software distribution and tool backed by Software Heritage, to our knowledge.

## I. INTRODUCTION

The findings that researchers publish are increasingly the outcome of computational processes where software plays a central role. Software becomes an integral part of all research scientific fields and more and more experiments rely on sets of complex software. Hence, computational processes must be transparent and verifiable and peers must be able to experiment with methodologies, i.e., software must held the same standards as any other scientific workflow. In concrete terms, the first implication is that source code must be publicly available, with a license that grants the right to use it, to study it, to modify it, and to share those modifications. UNESCO's Recommendation on Open Science [1] further states:

> In the context of open science, when open source code is a component of a research process, enabling reuse and replication generally requires that it be accompanied with open data and open specifications of the environment required to compile and run it.

The last part—*specifications of the environment*—is often overlooked or dismissed. Researchers sometimes provide an incomplete list of software requirements, often poorly cited or imprecisely identified; or they sometimes provide imprecise natural-language build instructions of their computational environment; or they sometimes provide large binary images (“containers”) which often prevents to study or modify the software. In practice, it is barely doable to access to the computational environment involved in the final publication, either to study or modify the full stack of source code, or to run another experiment with some variations of the computational process.

The challenge arises from the dual nature of software: humans read source code, while machines execute binaries. Reproducibility asks all the details on how binaries are produced from source code [2]. For example, compilers or interpreters transform source code into binary that an human deciphers with difficulties just by looking at the binary. Therefore, the part—*specifications of the environment*—requires both source code and its transformation; both are crucial. Since package managers automatize the complex tasks to deal with these transformations and now that software is an integral part of scientific workflows, package managers are a pillar of reproducible research and Open Science.

This paper focus on Guix: a software deployment tool that supports reproducible software deployment. It can be used as a “package manager” or as a standalone system, and Guix features include user specific package installation, transactional upgrades and rollbacks, packing containers, virtual machine instantiation. Note that Debian and Guix can coexist concurrently on the same running system.

Specifically, this paper highlights two features of Guix: 1. creating user customized packages and computational environment variants; and 2. source code archiving and rescue with Software Heritage, the largest publicly available archive of source code.

## II. BACKGROUND ON GUIX

A large community which is seeing growing [3], [4] develops Guix since 2012 [5]. As “package manager”, Guix can coexist concurrently without any conflict with other packager managers such as those found on GNU/Linux distributions, e.g., *apt*, *dnf*, *pip*, *conda*, etc. On the top of any GNU/Linux
distributions, Guix provides tooling for software deployment. For example, it is able to pack packages into containers as Docker [6] or Singularity or simply as relocatable tarballs. Moreover, it can also run as a standalone system—just like Debian.

Guix builds upon the *functional software deployment* model pioneered by Nix [7]. It reuses low-level mechanisms from Nix to implement the same paradigm, but Guix offers a unified implementation [8], from package definition to its own internal implementation, all relying on the same programming language [5]. In addition, such paradigm helps with *reproducible builds* and detecting software supply chain integrity [9]. These make it a tool of choice [10] when deploying software for reproducible research workflows.

Compared to package managers as `apt` or `conda`, a major difference with Guix is about the graph of package dependencies. Instead of capturing a list of package names and versions, and then let the package manager resolves the constraint set, Guix lets users capture the entire graph of package definitions. The user provides a Guix *revision* which pinpoints a whole collection of packages. Each revision specifies version numbers and also all the information required to configure and build the packages, including how to fetch the source code and its integrity checksum, and last, package dependencies (*recursively*). Knowing this revision, users can run the `guix time-machine` command to re-deploy the *exact same software environment* on a different machine or at a different point in time [2].

For instance, consider this command:

```
guix time-machine --commit=eb34ff1 \
  -- shell r r-harmony
```

It spawns a computational environment containing the packages `r` and `r-harmony` as defined by the Guix revision `eb34ff1` which dates from April 2022. The oldest revision reachable dates from 2019 (v1.0.0).

Unlike Debian, Guix is at its core a “source-based” deployment tool. However, the Guix project serves pre-built binaries, and Guix focuses on verifiable [11] and reproducible builds as mentioned above, thus it is highly recommended to download these pre-built binaries as substitutes [7] for local compilation. If the substitute is unavailable, then Guix locally builds. Therefore, depending on the pre-built binary availability of packages, for example dating from 2019 or 2022, Guix potentially rebuilds the packages `r` or `r-harmony`, and their missing dependencies too.

Guix only deploys software packages that have been *defined* in its own package collection. Guix itself provides almost 30 000 packages, and its own collection might be extended by third-party channels. For example, most of the packages from The Comprehensive R Archive Network (CRAN)<fnref n="1" /> or many from Bioconductor<fnref n="2" /> are automatically defined and included as Guix third-party package collection channels.

```
(list
  (channel
    (name 'guix')
    (url "https://git.guix.gnu.org/guix.git")
    (commit
      "eb34ff16cc9038880e87e1a58a93331fca37ad92")))
```

<caption>Fig. 1. Channels file.</caption>

Last, when the computational environment depends on third-party channels, the revision for each channel must also be captured. In that case, the option `--commit` above is replaced by a `channels.scm` file, which lists the revision of each channel. The command above reads:

```
guix time-machine -C channels.scm \
  -- shell r r-harmony
```

where Figure 1 shows the `channels.scm` file.

### III. GUIX PACKAGE TRANSFORMATION

To understand what the Guix feature provides, let us first describe Guix package definitions and second how to declare a computational environment.

#### A. Guix Package Definition

Figure 2 shows the definition of the `python-scikit-learn` package. This definition is simplified: metadata fields as synopsis or description are omitted as well as complete build options. Figure 2 illustrates how package definition are embedded in the Scheme programming language and how they are declarative [5]. Each definition declares metadata fields as name, version, license, source field, instructions on how to build the package and lists the direct dependencies. Each dependency is itself another Guix package definition, that's why it results a graph of dependencies. Moreover, this graph is directed and acyclic; it means, for example, that the package `openblas`, and neither its dependencies, recursively, depends on `python-scikit-learn`.

One important field to notice is the `sha256` field. This field specifies the cryptographic checksum of the source code. In this example, it refers to a Git check out, but source code can also be fetched through other methods such as other version control systems (Subversion, Mercurial, etc.) or over HTTPS (so-called `tarball`). This integrity cryptographic hash is twofold: on one hand, when Guix obtains a different hash, it aborts—bit-to-bit identical source code is a prerequisite for reproducible builds—and on the other hand, it helps in retrieving source code from Software Heritage.

Last, users can define their own packages and share their definitions via third-party channels (see above). Also, users could prefer keeping local their package definitions and store some with the other files of their research project, then using the command line option `--load-path`, they can temporarily extend the collection of available packages with their owns.

<footnote n="1">¹https://cran.r-project.org/, accessed 2025-06-10.</footnote>

<footnote n="2">²https://www.bioconductor.org/, accessed 2025-06-10.</footnote>
1 (define-public python-scikit-learn
2 (package
3 (name "python-scikit-learn")
4 (version "1.6.1")
5
6 (source
7 (origin
8 (method git-fetch)
9 (uri (git-reference (url
10 "https://github.com/scikit-learn/scikit-learn")
11 (commit version)))
12 (file-name (git-file-name name version))
13 (sha256 (base32
14 "08z1b58n31grfv142wi6rdwrfhrdhnzkkxhg19iag3zkvkcvxqj1")))
15
16 (build-system pyproject-build-system)
17 (arguments
18 (list
19 #:phases
20 #~(modify-phases %standard-phases
21 (add-before 'build 'configure
22 (lambda _
23 (setenv "SKLEARN_BUILD_parallel"
24 (number->string
25 (parallel-job-count)))))
26
27 (inputs (list openblas
28 python-jobjlib python-numpy
29 python-scipy python-threadpoolctl))
30 (license license:bsd-3))
31 ;; various fields omitted

<caption>Fig. 2. Package definitions of Python and Scikit-learn.</caption>

## B. Declaring a Computational Environment: manifest file

Consider the command above, and instead of listing the packages from the command line, Guix accepts that these packages are declared by a file. Figure 3 shows an example of such manifest file; for most scientific practitioners, the manifest file lists some packages. The command invocation becomes:

```
guix time-machine -C channels.scm \
  -- shell -m manifest.scm
```

As said, Guix offers a unified implementation relying on the same programming language. This manifest file might be arbitrarily complex and manipulate the package definitions. It allows to declare customized computational environments.

For example, consider the use case where you want to run the packages `r` and `r-harmony` provided by Guix, and not the default package `python-scikit-learn` but a customized one. Assume that the default compiler provided by the “revision” `channels.scm` is GCC at version 10.3.0 and this very same revision also provides the other GCC version 9.4.0. You want that the Python ecosystem is built with GCC@10 but the R ecosystem built with GCC@9.

Figure 4 shows a manifest file to achieve this use case. The simple example highlights how Guix helps in fine-controlling the graph of dependencies.

```
(specifications->manifest (list "r" "r-harmony"))
```

<caption>Fig. 3. Manifest file.</caption>

```
(use-modules (guix transformations))
1
2
#define transform
3
(options->transformation
4
'((with-c-toolchain . "r-minimal=gcc-toolchain@9")))
5
6
#define r-packages
7
(map specification->package (list "r" "r-harmony")))
8
9
#define python-packages
10
(map specification->package
11
(list "python" "python-scikit-learn")))
12
13
 packages->manifest
14
(append (map transform r-packages)
15
python-packages))
16
```

<caption>Fig. 4. Manifest file with package transformation.</caption>

## IV. SOURCE CODE ARCHIVING AND RESCUE

If the source code disappears, then the two tenets of the scientific method—the ability to verify and to experiment—are defeated; the entire foundation for reproducible deployment collapses. This scenario is far from unrealistic: source code hosting sites come and go, even those backed by large companies deemed “too big to fail” [12]. How much of the source code referenced by Guix packages has disappeared or has been tampered with? It is the question we asked ourselves and answered in [13]: we attempted to download the source code of all the packages found in Guix at the time of past releases, covering 5 years of history from version 1.0.0 (released in May 2019) to January 2024. We reproduce in Table I the findings of [13] consistent with those reported in an earlier study [14], and this highlights this statement: source code disappearing (link rot) is far from an unrealistic scenario.

Today, the situation cannot be better but possibly worse as the passing of time. Moreover, the fraction of missing package sources underestimates the real impact. When one package is unavailable from its original upstream URL as it appeared in Guix, all the packages depending on this one are also lost. Therefore, when one source code is missing in the graph of dependencies, we must replace it by the exact same source code verified by the integrity checksum, otherwise it is hard or impossible to know that the redeployment is exactly the same.

With the mission to collect, archive and share all publicly-available source code, Software Heritage [15] (SWH for short) has the potential to let us fill the gap.

<table><caption>TABLE I
“LINK ROT” EMPIRICAL EVALUATION OF ALL PACKAGE SOURCES OVER FIVE YEARS [13].</caption><thead><tr><th></th><th>May 2019<br>v1.0.0</th><th>Apr. 2020<br>v1.1.0</th><th>Nov. 2020<br>v1.2.0</th><th>May 2021<br>v1.3.0</th><th>Dec. 2022<br>v1.4.0</th></tr></thead><tbody><tr><td>#sources</td><td>8794</td><td>11659</td><td>13609</td><td>15520</td><td>20184</td></tr><tr><td>avail.</td><td>91.5%</td><td>92.4%</td><td>95.0%</td><td>95.7%</td><td>96.4%</td></tr><tr><td>missing</td><td>8.5%</td><td>7.6%</td><td>5.0%</td><td>4.3%</td><td>3.6%</td></tr><tr><td>hash mis.</td><td>87</td><td>63</td><td>69</td><td>66</td><td>52</td></tr></tbody></table>
## A. Software Heritage: Long-Term Source Code Archive

Software Heritage [15] (SWH) is a digital preservation initiative with the aim of collecting, preserving for the long-term, and providing access to the entire body of software, in the preferred form for making modifications to it, i.e., "source code". The SWH archive<fnref n="3" /> is the largest publicly available archive of software source code. At the time of writing it contains more than 17 billion unique source code files and 5.2 billion commits, coming from more than 380 million projects.

The connection between Guix and SWH goes both ways: first the Guix project ensures that the SWH archive ingests source code of packages Guix refers to, and second Guix falls back to retrieving source code from SWH; see [13] for the all implementation details.

## B. Automatic Source Code Recovery

Remind the latter command: It launches a computational environment containing the packages described by the file `manifest.scm` in the "revision" described by the file `channel.scm`. The challenge is gradual: first know that source code is effectively preserved by SWH; second be able to automatically recover from SWH; third be able to rebuild on a different machine or at a different point in time [16]. The second matters for being able to study or modify the source code when the third matters for being able to experiment with methodologies, the both are core tenets of the scientific methods.

The command above relies on Guix internal implementation as it was implemented in the "revision" described by the file `channel.scm`. And as any software development effort, bugs happen and are get fixed, eventually. However, because Guix lets users travel back in its history, those bugs make *automatic* recovery a real challenge. For an example from February 2024, the SWH Vault Web API started responding with HTTP redirects that Guix code did not follow<fnref n="4" />, and for another example from March 2023, CR/LF convention applied on Git repositories was different<fnref n="5" />. Now the past Guix revisions— which do not include these fixes—do not transparently recover.

These limitations are identified and mitigation is work in progress.

## V. CONCLUSION

The main effort presented here is an attempt to address two challenges—aligned with the two core tenets of the scientific methods. On one hand, we exposed how Guix helps in increasing software resilience. To our knowledge, Guix is the first free software distribution and tool backed by Software Heritage, the largest publicly available archive of source code. On the other hand, we exhibited how Guix helps in easing the experiments with computational environment variations. The cross-pollination between Guix and Debian continues to pave the way for producing better tools, ranging from reproducible builds or bootstrapping to long term or software variants.

## ACKNOWLEDGMENT

The author would like to thank Antoine R. Dumont, Antoine Eiche, Antoine Lambert, Ludovic Courtès and Timothy Sample for their decisive work on making source code archiving and rescuing from Software Heritage.

## REFERENCES

[1] UNESCO, "UNESCO Recommendation on Open Science," November 2021. [Online]. Available: https://www.unesco.org/en/natural-sciences/op en-science

[2] N. Vallet, D. Michonneau, and S. Tournier, "Toward practical transparent verifiable and long-term reproducible research using Guix," *Nature Scientific Data*, vol. 9, October 2022. [Online]. Available: https://doi.org/10.1038/s41597-022-01720-9

[3] The Guix contributors, "GNU Guix 1.0.0," May 2019. [Online]. Available: swh:1:rev:6298c3ffd9654d3231a6f25390b056483e8f407c;origin=https: //git.savannah.gnu.org/git/guix.git

[4] ——, "GNU Guix," Jan. 2024. [Online]. Available: swh:1:rev: 25bcf4eda05b501758b11a53823867dc500ac7d1;origin=https://git.sava nnah.gnu.org/git/guix.git

[5] L. Courtès, "Functional package management with Guix," in *European Lisp Symposium*, Madrid, Spain, June 2013. [Online]. Available: https://hal.inria.fr/hal-00824004/en

[6] S. Tournier, "(Re)Déploiement de conteneurs et machines virtuelles avec Guix," in *JRES (Journées réseaux de l'enseignement et de la recherche ) 2024*. Rennes, France: Renater, Dec. 2024. [Online]. Available: https://hal.science/hal-04893852

[7] E. Dolstra, M. de Jonge, and E. Visser, "Nix: A safe and policy-free system for software deployment," in *Proceedings of the 18th Large Installation System Administration Conference (LISA '04)*. USENIX, November 2004, pp. 79-92.

[8] L. Courtès, "Code Staging in GNU Guix," in *16th ACM SIGPLAN International Conference on Generative Programming: Concepts and Experiences (GPCE'17)*, Vancouver, Canada, Oct. 2017. [Online]. Available: https://inria.hal.science/hal-01580582

[9] C. Lamb and S. Zacchiroli, "Reproducible builds: increasing the integrity of software supply chains," *IEEE Software*, no. 2, p. 62-70, March 2022.

[10] J. Malka, S. Zacchiroli, and T. Zimmermann, "Does functional package management enable reproducible builds at scale? yes." in *2025 IEEE/ACM 22nd International Conference on Mining Software Repositories (MSR)*, 2025, pp. 775-787.

[11] L. Courtès, "Building a secure software supply chain with GNU Guix," *The Art, Science, and Engineering of Programming*, vol. 7, 06 2022.

[12] E. Escamilla, M. Klein, T. Cooper, V. Rampin, M. C. Weigle, and M. L. Nelson, "The rise of GitHub in scholarly publications," in *Linking Theory and Practice of Digital Libraries*, G. Silvello, O. Corcho, P. Manghi, G. M. Di Nunzio, K. Golub, N. Ferro, and A. Poggi, Eds. Cham: Springer International Publishing, 2022, pp. 187-200.

[13] L. Courtès, T. Sample, S. Zacchiroli, and S. Tournier, "Source code archiving to the rescue of reproducible deployment," in *Proceedings of the 2nd ACM Conference on Reproducibility and Replicability*, ser. ACM REP '24. New York, NY, USA: Association for Computing Machinery, 2024, p. 36-45. [Online]. Available: https://doi.org/10.1145/3641525.3663622

[14] E. Escamilla, M. Klein, T. Cooper, V. Rampin, M. C. Weigle, and M. L. Nelson, "Cited but not archived: Analyzing the status of code references in scholarly articles," in *Leveraging Generative Intelligence in Digital Libraries: Towards Human-Machine Collaboration: 25th International Conference on Asia-Pacific Digital Libraries, ICADL 2023, Taipei, Taiwan, December 4-7, 2023, Proceedings, Part II*. Berlin, Heidelberg: Springer-Verlag, 2023, pp. 194-207. [Online]. Available: https://doi.org/10.1007/978-981-99-8088-8_17

[15] R. D. Cosmo and S. Zacchiroli, "Software Heritage: Why and how to preserve software source code," in *Proceedings of the 14th International Conference on Digital Preservation*, iPRES 2017, Kyoto, Japan, September 25-29, 2017, S. Hara, S. Sugimoto, and M. Goto, Eds., 2017. [Online]. Available: https://hdl.handle.net/11353/10.93106/14

[16] L. Courtès, "Adventures on the quest for long-term reproducible deployment," March 2019, https://guix.gnu.org/en/blog/2024/adve ntures-on-the-quest-for-long-term-reproducible-deployment/.

<footnote n="3">³https://archive.softwareheritage.org, accessed 2025-06-10.</footnote>

<footnote n="4">⁴https://issues.guix.gnu.org/69058, accessed 2025-06-10.</footnote>

<footnote n="5">⁵https://issues.guix.gnu.org/61910, accessed 2025-06-10.</footnote>