From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#22629: [PATCH 0/4] 'guix pull' produces a self-contained Guix Date: Thu, 19 Jul 2018 14:15:35 +0200 Message-ID: <87fu0fv2u0.fsf@gnu.org> References: <87fu45ve2z.fsf@gnu.org> <20180531144337.16298-1-ludo@gnu.org> <87601bkf40.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35066) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fg7qp-0002EO-37 for bug-guix@gnu.org; Thu, 19 Jul 2018 08:16:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fg7qk-0005WD-NI for bug-guix@gnu.org; Thu, 19 Jul 2018 08:16:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:42577) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fg7qk-0005W4-Hv for bug-guix@gnu.org; Thu, 19 Jul 2018 08:16:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fg7qk-0008Ab-9c for bug-guix@gnu.org; Thu, 19 Jul 2018 08:16:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87601bkf40.fsf@gmail.com> (Chris Marusich's message of "Wed, 18 Jul 2018 21:45:51 -0700") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Chris Marusich Cc: 22629@debbugs.gnu.org Hello Chris, Thanks for your feedback! Chris Marusich skribis: > I was surprised that "guix pull" doesn't build the guix package via the > usual mechanisms (e.g., the way it would be built if I ran "guix build > guix"). The new "guix pull" code builds a profile, so it seems like we > could put packages in there (e.g., a guix package that inherits from the > original but replaces the origin with a Git checkout). However, instead > of re-using the build logic encapsulated in the guix package, it looks > like we build Guix piece by piece using custom build logic in (guix > self). Why do we do that? There=E2=80=99s a couple of problems that we=E2=80=99re trying to fix, whic= h were discussed at : 1. Bootstrapping: how do we built a new Guix from an already-installed, older Guix? 2. Efficiency: how do we avoid recompiling every since Scheme file at each revision? The answer to #2 is, of course, to have a finer-grain view on what needs to be built. We have makefiles that have view at the file level, and here we essentially want to do what makefiles do, but we also want to introduce dependencies (our makefiles do not declare dependencies among Scheme files, which sometimes lead to those infamous ABI issues.) We could have defined package objects to describe each of the various subparts of Guix: a =E2=80=9Cguix-core=E2=80=9D package, a =E2=80=9Cguix-pa= ckages=E2=80=9D package, etc. But it=E2=80=99s not a good fit: these aren=E2=80=99t really packages, ther= e=E2=80=99s no UI to access them as such anyway, and we=E2=80=99re closer to the abstraction lev= el of a makefile than to the abstraction level of a package. So I chose to define a custom type in (guix self). Each node represents a group of files, in particular Scheme files that need to be compiled; nodes can have edges (the =E2=80=98dependencies=E2=80=99 field). = On top of that there are helper procedures to create and manipulate nodes. For instance, =E2=80=98scheme-nodes=E2=80=99 creates a node that builds the clo= sure of a list of .scm files, minus the files already built by its dependencies. The end result is that the full Guix consists of half a dozen of Scheme derivations. Derivations at the root of the DAG (e.g., =E2=80=9Cguix-core= =E2=80=9D) hopefully change quite infrequently, and as such we don=E2=80=99t have to rebuild everything at each revision. As I wrote before in the issue above, there=E2=80=99s room for improvement.= In particular we could split nodes further. I hope this clarifies things! Ludo=E2=80=99.