Re: Towards reproducibly Jupyter notebooks with Guix-Jupyter

[zimoun <zimon.toutoune@gmail.com>]

On Wed, 23 Oct 2019 at 14:15, Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:
>
> Hi Simon,
>
> > I am not sure to understand everything, so my questions are:
> >
> >  - Do you consider binaries coming from multiple commits and/or
> > multiple channels?
>
> 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?
I mean, from my experience, I work by steps. Say I use package foo
coming from the commit C1 and I complete the first step. Then, weeks
later, I need the package bar and it is not provided by the commit C1,
so I "guix pull" and the second step is completed with the commit C2.
However, the package foo has been grafted (or update) between C1 and
C2. Therefore, it is becoming hard to run the 2 steps in one-go.

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.)

Back to my example, all the computations done with the commit C1 have
to be re-done with all the binaries coming from the commit C2---in
order to have only one commit. Or the redo implies the 2 steps---when
it is 2, it seems doable however if it is more it won't.

What do you think?


> >  - Why splits the channel file and the manifest file? I am thinking to
> > improve the DSL of the manifest file.
>
> I have thought about this as well, but I am not convinced this is a good
> idea, for two reasons.
>
> First, the manifest file is hand-written, the channel file is produced
> by "guix describe". How would a combined file be created? And how would
> it be updated? The two main kinds of update are 1) updating the software
> and 2) changing the components of the environment. Today each part is
> covered by one file, so there is no conflict. With a single file, would
> "guix pull" have an option to patch in a new commit number?

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


> What a combined file would make sense for is saving a profile to a
> manifest file. As far as I know there is no support for that at the
> moment, but it could be useful.

I agree. :-)

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

All the best,
simon