Re: Towards reproducibly Jupyter notebooks with Guix-Jupyter

[Konrad Hinsen]

zimoun <address@hidden> writes:

>> No, at least not explicitly. My goal is reproducing computations from
>> the past, so I need to re-animate old manifest files. These could of
>> course contain references to inferior-packages, so they could be
>> multi-commit, but this is not my focus.
>
> But does it fit with the current practice?

With mine, yes :-)

Installing packages one by one into my profile is something I only do
for quick tests. All my profiles are defined by manifest files under
version control, and occasionally updated as a whole.

If there were a straightforward way to save profiles to a manifest
file, I might be less strict about this procedure, though I don't find
it constraining in practice. It fits well with my older habit of having
all configuration files under version control.

> I do not know if it is a way to go: allow profile/environment
> populated with binaries from different commits (without speaking about
> possible clash.)

I'd say it's doable, but so far not implemented. Restoring such an
environment is likely to be expensive, as you have to download multiple
Guix commits and then maybe compile dozens of versions of old compilers
etc.

Assuming that one day in the near future, all scientists use Guix and
routinely publish their manifest files, I'd expect reviewers to ask
authors to clean up their manifest files for the benefit of everyone
else. So I adopt this habit now before I am forced to ;-)

> This information is already available in one location:
> <profile>/manifest, I guess.

Indeed, but it's an undocumented feature for now. The format is
undocumented and not accepted by "guix package" or "guix environment".

> Pierre wrote an example to bridge the profile to the manifest.
> See https://ambrevar.xyz/guix-advance/index.html
> section Generate a manifest  (bottom)

Interesting, but it records only one commit, for the current Guix.
If you have older non-updated packages, this will go unnoticed.
I see this mainly as a tool for migrating from historical-accident
profiles to managed profiles, but that's perhaps just my own bias.

Cheers,
  Konrad