Hi! David Craven <da...@craven.ch> skribis:
> Ah yes, that makes sense. Thank you for explaining. I think I'm > understanding the general design pattern better: > > Build side code that uses a record from gnu/system is a gexp in > gnu/system. This gexp is passed to a function in gnu/build so that > gnu/build itself doesn't need to import gnu/system and can avoid > recursive imports. One of the goals of using Scheme on both sides is code reuse. However, things like (guix build utils) are inherently “build side”, hence the name. In addition, it wouldn’t make sense to pull (guix store), (guix packages), and friends on the “build side”, because these things cannot be used there since the build environment doesn’t give access to the daemon (IOW, a build process cannot talk to the daemon, it’s not recursive.) Thus, the (guix build …) module space also serves as a way to distinguish things and avoid pulling all of the Guix modules unwillingly on the build side. It introduces some sort of a frontier between the build side and the host side (info "(guix) G-Expressions"). But borders are unbearable and sometimes there’s useful stuff that we want to use freely on both sides, like this <file-system> record type. :-) Ludo’.
