From mboxrd@z Thu Jan 1 00:00:00 1970 From: zimoun Subject: Re: Towards reproducibly Jupyter notebooks with Guix-Jupyter Date: Wed, 23 Oct 2019 18:49:49 +0200 Message-ID: References: <87lftt57ux.fsf@inria.fr> <87imowwt3i.fsf@gnu.org> <875zkru70u.fsf@inria.fr> <87imorqx0w.fsf@inria.fr> <87y2xd5bmb.fsf@inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:52772) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iNJpj-0003Ae-7m for guix-devel@gnu.org; Wed, 23 Oct 2019 12:50:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iNJph-00019H-QM for guix-devel@gnu.org; Wed, 23 Oct 2019 12:50:03 -0400 Received: from mail-qk1-x731.google.com ([2607:f8b0:4864:20::731]:39518) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iNJph-000199-KI for guix-devel@gnu.org; Wed, 23 Oct 2019 12:50:01 -0400 Received: by mail-qk1-x731.google.com with SMTP id 4so20390898qki.6 for ; Wed, 23 Oct 2019 09:50:01 -0700 (PDT) In-Reply-To: List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Konrad Hinsen Cc: Guix Devel , =?UTF-8?Q?Ludovic_Court=C3=A8s?= On Wed, 23 Oct 2019 at 14:15, Konrad Hinsen 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: /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