Re: persistent reproducibility ?

[Alex Sassmannshausen]

Hi Zimoun,

zimoun writes:

> Hi!
>
> On 21 March 2017 at 17:19, Ludovic Courtès <address@hidden> wrote:
>> Hello!
>>
>> zimoun <address@hidden> 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.
>
> Thank you for your quick answer.
>
> I was not aware of the `guix pull' commit specification. I am going to try.
>
> If I understand well your both explanations, my question overlaps the
> current discussion about Channels. I mean, in the same way that people
> currently include in their project conda shell files or spack python
> files or whatever in this flavour, they will replace by Guile ones
> (even if lisp is hard to sell ;-), and there is questions about how to
> glue these channels.
>
> One of the issues is that the Guix packages tree will never include
> some softwares, even if they are open source. Because the authors
> apply weird licences or non-GNU compliant licences, or simply because
> authors are not so motivated to push. Even if I totally agree with the
> paragraph about Proprietary Softwares in your cited paper, it is just
> a fact from my humble opinion.
>
>
> Therefore, what should be the "standard" way to manipulate against
> history version external and decentralised packages ? and guix repo
> packages too ?
>
>
> Well, if I understand your both answers, the correct process should
> be: Alice publishes a paper containing the exact version (commit hash
> or revision number or origin hash) of both the source tree and the
> recipe tree, and their both uri location, and then, Joe "just" needs
> to check out each (manually for now or possibly by nice UI glue).
>
> From my current knowledge about Guix, considering two moments t1 and
> t2, separated by let say several month, a way to build at t2 the
> bit-identical `foo' of t1 should to provide at t1 a sort of manual
> meta-package pointing to exacts version through `origin' and
> `git-fetch' (imaging that `hg-fetch' and `svn-fetch' would be added,
> or not!). If one piece of this information about the exact versions is
> not pointed out at t1, it appears to me almost impossible to insure
> the building of the bit-identical at t2.
> If I understand well, this way is what you describe Alex, right ?

Right — so I think I was a bit unclear in my first email.

A guix package recipe, as you point, points to an exact revision/version
of software (either through a version spec, or through a commit hash).
The package's dependencies are specified as pure scheme variables that
in turn resolve to package recipes.

These package recipes in turn specify the exact revision of the
dependencies.

So for `foo` to be fully reproducible at t1 you require the package tree
that corresponds to `foo`, `bar` & `baz` at t1.  This tree would carry
all the meta information related to `foo` and it's exact dependencies.

I guess you may also need the correct version of Guix.  I'm not sure how
that affects reproducibility, so I won't comment further on that.

In any case, if you have `foo`, `bar` & `baz` as part of a guix source
tree, then the revision of that source tree at t1 should be sufficient
to reproduce `foo` at t1.

I guess this is where the discussion of channels, and whether to package
the programs for Guix itself or somehow outside become relevant, but
again, I don't feel super qualified to comment on this.

All the meta-information required is carried by that revision.

I wasn't sure what you meant by manual-metapackage, so I hope my answer
provides you with the information you were looking for!

I won't comment on the latter parts of your email, as it sounds like
it's more related to fully reproducible environments rather than
individual packages.  Personally I use manifests, but that might not be
good enough for your requirements.

HTH,

Alex