Reproducible Research Hackathon
Several submissions to the recent Ten Years Reproducibility Challenge organized by ReScience took advantage of GNU Guix, as discussed earlier.
This challenge helped highlight again ways in which research practices can and must be improved. For instance, one review explains that archival of the source code is not enough and another points evolutions and breaking changes of well-known scientific libraries.
We propose to collectively tackle some of the issues on Friday, July 3rd:
- identify stumbling blocks in using Guix to write end-to-end pipelines,
- document how to achieve this,
- feed the Guix-Past channel by other old packages,
guix.scmfor some of the Ten-Year papers.
Feel free to contact us at
you would like to hack with us.
We will meet at 9:30 CEST on the
#guix-hpc channel of irc.freenode.net.
You can use this web client (tweaking the
channel) to reach us.
Here is a non-exhaustive list of ideas, inspired by contributions to the Ten-Year Reproducibility Challenge run by the journal ReScience C:
Package old software that is of sufficiently wide interest.
Package highly specialized research software - where packaging means writing a
guix.scm. The long-term goal is to learn how to make this kind of packaging easier by providing templates reusable by scientists. Typical real-world examples sorted by difficulty order:
- Standard Fortran
code with only the
LAPACKlibraries as dependencies.
- Medium-sized Fortran
code using a
- Mixed C-Fortran
Autotools; the difficulty arises from the requirement of the abandoned
- Medium-sized Fortran code adding its own wrapper aroung the compiler.
- Standard Fortran code with only the popular
- Fully automated reproductions of results (typically figures). This
submission is a
fully reproducible replicate based on Debian and its
debuerreotypesystem. How do it compare with Guix?
There's a lot we can do and we'd love to hear your ideas!
Drop us an email at