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’s a couple of problems that we’re trying to fix, which 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 “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 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’.