From: ludo@gnu.org (Ludovic Courtès)
To: zimoun <zimon.toutoune@gmail.com>
Cc: help-guix@gnu.org
Subject: Re: persistent reproducibility ?
Date: Tue, 21 Mar 2017 17:19:33 +0100 [thread overview]
Message-ID: <87shm6wqju.fsf@gnu.org> (raw)
In-Reply-To: <CAJ3okZ1H508UC5gZYSeoZAxzsnCoNac3CTm6eCAC5FSsx-BxQA@mail.gmail.com> (zimoun's message of "Tue, 21 Mar 2017 12:15:25 +0100")
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’.
next prev parent reply other threads:[~2017-03-21 16:19 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-21 11:15 persistent reproducibility ? zimoun
2017-03-21 14:49 ` Alex Sassmannshausen
2017-03-21 16:19 ` Ludovic Courtès [this message]
2017-03-22 17:39 ` zimoun
2017-03-23 8:44 ` Alex Sassmannshausen
2017-03-23 15:33 ` zimoun
2017-03-23 12:32 ` Ricardo Wurmus
2017-03-23 16:46 ` zimoun
2017-03-24 15:45 ` Ludovic Courtès
2017-03-25 13:07 ` zimoun
2017-03-24 5:39 ` Chris Marusich
2017-03-24 12:05 ` Quiliro
2017-03-26 9:39 ` Chris Marusich
2017-03-26 15:03 ` Quiliro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87shm6wqju.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=help-guix@gnu.org \
--cc=zimon.toutoune@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).