From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Hinsen Subject: Re: Towards reproducibly Jupyter notebooks with Guix-Jupyter Date: Wed, 23 Oct 2019 14:15:34 +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 Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:33098) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iNFYD-0003Fl-61 for guix-devel@gnu.org; Wed, 23 Oct 2019 08:15:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iNFYC-0001TR-2e for guix-devel@gnu.org; Wed, 23 Oct 2019 08:15:41 -0400 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:43409) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iNFYB-0001Ra-Kq for guix-devel@gnu.org; Wed, 23 Oct 2019 08:15:40 -0400 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: zimoun Cc: Guix Devel , Ludovic =?utf-8?Q?Court=C3=A8s?= 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. > - 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? Second, combining both informations would likely require a restriction of what is allowed in a manifest file. For example, only allow package specifications by name and version, without transformations. Otherwise the implementation would be quite complicated. Imagine someone applying a transformation using today's guix to a package from last year's guix that didn't have a feature used in the transformation. 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. Cheers, Konrad.