Re: persistent reproducibility ?

[ludo@gnu.org (Ludovic Courtès)]

Hello!

zimoun <zimon.toutoune@gmail.com> skribis:

> The typical research workflow is:
>
> - Alice proposes new method and/or algorithm, publishes a paper and
> illustrates that by the software `foo'. Let the best case: Alice
> provides a Guix "recipe", and all the material is stored in Github
> (let say). This software `foo' depends on both `bar' and `baz', one
> also in Github and the other one included in the Guix package tree.
>
> - It is easy for Bob to check out and experiment. Guix allows him to
> straightforwardly build the bit identical `foo' (all dependencies
> included). Nice!! Repeatability is there for free.
>
> - New features are added to `foo', `bar' and `baz'. All the codes
> evolve, especially the research ones.
>
> - Now, Joe is implementing the Alice's method; science means
> reproducible. And Joe would like to compare his implementation to the
> Alice one provided by `foo'. However, how ? The `foo' "ecosystem" has
> changed with the new features. Therefore, Joe has to navigate in the
> Git tree of the Guix "recipe" of `foo', `bar', `baz' to be able to
> produce the bit-identical `foo' used in the initial paper. I mean, it
> is what I understand to do, and it does not seem reasonable.
>
>
> My question is: does Guix provide any mechanism to build reproducible
> software over the time ?

To add to what Alex wrote, yes it’s possible, though there are UI gaps
that we’ll be filling.  If you do a checkout of the Guix commit that
Alice mentioned in the paper, you can build the exact same software as
Alice.  ‘guix pull’ allows you to specify the Guix commit you’d like to
use, but it’s not that convenient that it’s something we’d like to
improve.

Ricardo and I wrote about the kind of workflows you describe in
<https://arxiv.org/abs/1506.02822>.  I hope you’ll find it interesting!

> Last, `foo' and `bar' are stored in two Github repositories. And they
> should disappear.
> ( I am not talking if it is good or not to use github, right now, it
> just is used by many teams of researchers )
>
> Could we used the Software Heritage initiative to maintain a kind of
> persistency ?
> https://www.softwareheritage.org

Definitely!  Software Heritage does not expose it yet, but when it does,
we can add it as a fallback mirror in our (guix git-download) module.
(I’ve discussed our use case with the Software Heritage folks a few
times, so they’re aware of it.  ;-))

I think the big picture is (where each arrow means “depends on”):

  repro science -> repro software environments -> stable archive

Things like ReScience can do the first step, Guix can do the second one,
and Software Heritage does the third one.

Thanks for sharing your use case!

Ludo’.