GNU bug report logs - #22629
Towards a new 'guix pull'

Previous Next

Full log

View this message in rfc822 format

From: ludo <at> gnu.org (Ludovic Courtès)
To: Chris Marusich <cmmarusich <at> gmail.com>
Cc: 22629 <at> debbugs.gnu.org
Subject: bug#22629: [PATCH 0/4] 'guix pull' produces a self-contained Guix
Date: Thu, 19 Jul 2018 14:15:35 +0200

Hello Chris,

Thanks for your feedback!

Chris Marusich <cmmarusich <at> gmail.com> 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’s a couple of problems that we’re trying to fix, which were
discussed at <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27284#133>:

  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 “guix-core” package, a “guix-packages” package, etc.
But it’s not a good fit: these aren’t really packages, there’s no UI to
access them as such anyway, and we’re closer to the abstraction level of
a makefile than to the abstraction level of a package.

So I chose to define a custom <node> 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 ‘dependencies’ field).  On top of
that there are helper procedures to create and manipulate nodes.  For
instance, ‘scheme-nodes’ creates a node that builds the closure 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., “guix-core”)
hopefully change quite infrequently, and as such we don’t have to
rebuild everything at each revision.

As I wrote before in the issue above, there’s room for improvement.  In
particular we could split nodes further.

I hope this clarifies things!

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.