Provide reproducible software environment deployment with GNU Guix

[civodul]

Hello!

As part of a Reproducible Research hackathon, we're looking into taking advantage of Guix to support reproducible deployment for submissions to ReScience C.

This pulls requests adds two files that let us deploy the software environment of this computational experiment in a reproducible fashion. I tested it on a local cluster at my research institute that runs Slurm 22.05; apart from Slurm itself, all the packages are provided by Guix. I also added a GitHub action to build the software environment upon push.

The figures I obtain all look similar to those in the published article, with one exception: Figure 2.A ("attractors"), as shown below.

I haven't tried to analyze the reason of this discrepancy (I'm not an expert in this field). Any ideas?

Cc: @rougier @khinsen

[rougier]

Not sure what could be the reason. Did you try to contact authors?

[suhail-singh]

out of curiosity, shouldn't channel inferiors (that provide packages versions which are as close as possible to the minimal version constraints in requirements.txt) be defined?

[khinsen]

That is more of a philosophical than a technical question. It depends on the criteria that the authors applied to define those minimal version constraints, and that is hardly ever documented. In practice, judging from my own experience, version constraints are rarely useful for reproducibility. The fundamental assumption that "x.x or higher" yields the same results is simply wrong. Only strict version equality (same commit ID) has practical value.

[suhail-singh]

"Konrad Hinsen" ***@***.***> writes:

That is more of a philosophical than a technical question.

It was intended as a practical question. While this is a PR on a project that's replicating some research, I, perhaps incorrectly, thought the intent here was to make said replication reproducible (as opposed to modifying the replication such that it's reproducible).

It depends on the criteria that the authors applied to define those minimal version constraints, and that is hardly ever documented.

True.

In practice, judging from my own experience, version constraints are rarely useful for reproducibility. The fundamental assumption that "x.x or higher" yields the same results is simply wrong.

True. Thank you for elaborating.

Only strict version equality (same commit ID) has practical value.

Okay, agreed.

…

-- Suhail