From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id cDE2GS0skmPndwEAbAwnHQ (envelope-from ) for ; Thu, 08 Dec 2022 19:25:49 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id +BlYGC0skmPk+AAAG6o9tA (envelope-from ) for ; Thu, 08 Dec 2022 19:25:49 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id B16FB2254A for ; Thu, 8 Dec 2022 19:25:48 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p3La9-0001Qb-Om; Thu, 08 Dec 2022 13:25:17 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p3La6-0001QK-JZ for guix-devel@gnu.org; Thu, 08 Dec 2022 13:25:14 -0500 Received: from knopi.disroot.org ([178.21.23.139]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p3La3-0000yk-52 for guix-devel@gnu.org; Thu, 08 Dec 2022 13:25:14 -0500 Received: from localhost (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id CB5EB40837 for ; Thu, 8 Dec 2022 19:25:08 +0100 (CET) X-Virus-Scanned: SPAM Filter at disroot.org Received: from knopi.disroot.org ([127.0.0.1]) by localhost (disroot.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VT_GUQbwqVnU for ; Thu, 8 Dec 2022 19:25:04 +0100 (CET) Content-Type: multipart/signed; boundary=7f149c2c581bc3c0015b90a4e544ea0729385b4245535dbd0b2c74be6f8e; micalg=pgp-sha512; protocol="application/pgp-signature" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1670523904; bh=WhYeJ/Q+cHtiJnNrtMpgTECz1he+p3P4CLNVeTQ2dAw=; h=Subject:From:To:Date; b=PR3aR9vEOTz9i4OVjBpslQYG1TrhHNsy28vhkbUG1NL/HlKgmuL9NrbzclT3Sdz4r WhNMsusOY3jamS3cEpJ9BIyyszcM/jKYJgFA3uaGVKdvwm5LoRDdgNxGGkthO/rPnU wQQUMZaYDaPJ/NaZ3B9oKhZRd2V36d1GrVMlPTLTp/1v7lS1Ae+OJZFgUMpMiJuEfd Fctcjau7Ziid66uUn1I2cepmKejGhMWfO3HXqfFao1ZYEDOgdAGGcOZs4/1hmzlQUL wfYCND1hXktc0jKRA/LQtYJEVWNbV8keH6fMdUkGegNuyyTYbgX5ydhpE7EI5Vs1J/ 0MuZQ6aV40o0Q== Subject: Dissecting Guix -- blog post series From: "(" To: Date: Thu, 08 Dec 2022 18:24:05 +0000 Message-Id: Received-SPF: pass client-ip=178.21.23.139; envelope-from=paren@disroot.org; helo=knopi.disroot.org X-Spam_score_int: -19 X-Spam_score: -2.0 X-Spam_bar: -- X-Spam_report: (-2.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MIME_HEADER_CTYPE_ONLY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, WEIRD_QUOTING=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list 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+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1670523949; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:content-type:content-type:list-id: list-help:list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=8QRBZ3H44jG9Hzge7eYj07jIJd3ybmVyRASynXoC+/Q=; b=J6AhZRwcQnidjhugoM9EbaLiWTevyNHbOmkizQP0A9e6wOmPQHTas2su3X3wZFe3mYjCV7 Dub62d2CqxWQ5V/vXtPm7O6d/vomNlR2RSXXm9FNPSkU3RP64dVIuQmUFReMw1m7cmnKAD lKkCP5EwaYIAFcBjUWjSpm5SfkcMwW8lkhnqR6FJUZwcwb5qUwn755fT19M+xXfqH9A5Fn 7gj4DV+sPOVdMbAsT2FPXuAg16J0/IgfUVd1bFSTG2PaWoYLyyqhc5LG/dAQI2/jE7xbMp mszue2O8yzuY5ZQTpArG3Pes5I2R5OQVwlFG8ZKYQn6Rz/JZRyrD8MfxL7uaLg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1670523949; a=rsa-sha256; cv=none; b=qcy3ioYo8U0Biej/GDMSsshDRnsSDydkXjApjeVvfV5xlvIycRsMXUOAZPBOHSKTlpzvu0 /xa1dlb5sVZb9iqots07Irz7u+jzOU6m1vBEDgNHL475+5IH12Yx8clQxztGMwYxhJMKsp Jz8VNdnuGtuo/K/qKqQcRfvFBB8HJNE2UKknrQbsTS2P/RnlhRfbMVnP8jmVM87RUjAnn+ lepTRfB4PlDtsS9RA0+BcKldJ354Kcvk2xa86ybB2XRhYgD4dez9eUR1POlSbzBuumC6A5 ncNRwP+YyGU0+D/jM8ZzRjQpkhUkt+ZWb0tIQb8F7mnHqbApyW/nygo2hTOwgg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=disroot.org header.s=mail header.b=PR3aR9vE; dmarc=pass (policy=reject) header.from=disroot.org; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -8.66 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=disroot.org header.s=mail header.b=PR3aR9vE; dmarc=pass (policy=reject) header.from=disroot.org; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: B16FB2254A X-Spam-Score: -8.66 X-Migadu-Scanner: scn0.migadu.com X-TUID: U3q0Pghu3ubQ --7f149c2c581bc3c0015b90a4e544ea0729385b4245535dbd0b2c74be6f8e Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Heya! Some of you may have seen on IRC that I've been writing a post for the Guix blog that I hope will form the first part of a series. This series aims to dissect the internals of Guix, from bottom to top. Perhaps they could go i= n the cookbook once the series is done? My aim is to write the following pos= ts (complete with cheesy titles :P), hopefully one per week: * Dissecting Guix, Part 1: Derivations Discusses derivations, the bottom layer of the Guix compilation tower, and dissects some example derivations. A draft of this post may be found below. Please feel free to critique! :) * Dissecting Guix, Part 2: The Humble G-Expression Talks about g-expressions and why they're necessary, explains file-like obj= ects, and provides demonstrations of each kind of file-like. * Dissecting Guix, Part 3: Packages A walkthrough for package creation. * Dissecting Guix, Part 4: Monads ``mlet'', ``>>=3D'', ``define-monad'', ``return'', and all that. * Dissecting Guix, Part 5: Profiles and Search Paths Explores profiles and search paths. * Dissecting Guix, Part 6: Goings-On in the Build Container Explains build systems, examines a build script, and talks about what exact= ly happens when a package is built. Also demonstrates some of the ``(guix build utils)'' APIs. * Dissecting Guix, Part 7: Record Types Demonstrates the ``(guix records)'' API in all its glory. * Dissecting Guix, Part 8: Substitutes and Grafts Discusses substitutes, and that persistent thorn in our sides, grafting. * Dissecting Guix, Part 9: Cross-Compilation Building packages on architecture X for architecture Y, and how that all works. * Dissecting Guix, Part 10: Services Walks you through the process of creating a service, and thouroughly explai= ns system configuration. * Dissecting Guix, Part 11: Home Services Similar to Part 9, except it's about ``guix home'', of course. * Dissecting Guix, Part 12: Writing a Subcommand Guides you through the process of adding a new command to Guix with the extensions feature, demonstrating several utility APIs in the process. * Dissecting Guix, Part 13: Lending a Hand How to edit the Guix source code and submit patches to be reviewed by the lovely Guix community! -- ( title: Dissecting Guix, Part 1: Derivations and Derivation date: TBC author: ( tags: Dissecting Guix, Functional package management, Programming interface= s, Scheme API --- To a new user, Guix's functional architecture can seem quite alien, and possibly offputting. With a combination of extensive `#guix`-querying, determined manual-reading, and plenty of source-perusing, they may eventually figure out how everything fits together by themselves, but this can be frustrating and often takes a fairly long time. However, once you peel back the layers, the "Nix way" is actually rather elegant, if perhaps not as simple as the mutable, imperative style implemented by the likes of [`dpkg`](https://wiki.debian.org/dpkg) and,=20 [`pacman`](https://wiki.archlinux.org/title/pacman). This series of blog posts will cover basic Guix concepts, taking a "ground-up" approach by dealing with lower-level concepts first, and hopefully make those months of information-gathering unnecessary. Before we dig in to Guix-specific concepts, we'll need to learn about one inherited from [Nix](https://nixos.org), the original functional package manager and the inspiration for Guix; the idea of a _derivation_ and its corresponding _store items_. These concepts were originally described by Eelco Dolstra, the author of Ni= x, in their [PhD thesis](https://edolstra.github.io/pubs/phd-thesis.pdf); see _=C2=A7 2.1 The Nix store_ and _=C2=A7 2.4 Store Derivations_. # Store Items As you almost certainly know, everything that Guix builds is stored in the _store_, which is almost always the `/gnu/store` directory. It's the job o= f the [`guix-daemon`](https://guix.gnu.org/manual/en/html_node/Invoking-guix_= 002ddaemon.html) to manage the store and build things. If you run [`guix build PKG`](https://guix.gnu.org/manual/en/html_node/Invoking-guix-b= uild.html), `PKG` will be built or downloaded from a substitute server if available, an= d a path to an item in the store will be displayed. ``` $ guix build irssi /gnu/store/v5pd69j3hjs1fck4b5p9hd91wc8yf5qx-irssi-1.4.3 ``` This item contains the final result of building [`irssi`](https://irssi.org= ). Let's peek inside: ``` $ ls $(guix build irssi) bin/ etc/ include/ lib/ share/ $ ls $(guix build irssi)/bin irssi* ``` `irssi` is quite a simple package. What about a more complex one, like [`glib`](https://docs.gtk.org/glib)? ``` $ guix build glib /gnu/store/bx8qq76idlmjrlqf1faslsq6zjc6f426-glib-2.73.3-bin /gnu/store/j65bhqwr7qq7l77nj0ahmk1f1ilnjr3a-glib-2.73.3-debug /gnu/store/3pn4ll6qakgfvfpc4mw89qrrbsgj3jf3-glib-2.73.3-doc /gnu/store/dvsk6x7d26nmwsqhnzws4iirb6dhhr1d-glib-2.73.3 /gnu/store/4c8ycz501n2d0xdi4blahvnbjhd5hpa8-glib-2.73.3-static ``` `glib` produces five `/gnu/store` items, because it's possible for a packag= e to produce multiple [outputs](https://guix.gnu.org/manual/en/html_node/Pack= ages-with-Multiple-Outputs.html). Each output can be referred to separately, by prefixing a package's name wi= th `:OUTPUT` where supported. For example, this [`guix install`](https://guix.gnu.org/manual/en/html_node/Invoking-guix-pac= kage.html) invocation will add `glib`'s `bin` output to your profile: ``` $ guix install glib:bin ``` The default output is `out`, so when you pass `glib` by itself to that command, it will actually install `glib:out` to the profile. `guix build` also provides the `--source` flag, which produces the store item corresponding to the given package's downloaded source code. ``` $ guix build --source irssi /gnu/store/cflbi4nbak0v9xbyc43lamzl4a539hhb-irssi-1.4.3.tar.xz $ guix build --source glib /gnu/store/d22wzjq3xm3q8hwnhbgk2xd3ph7lb6ay-glib-2.73.3.tar.xz ``` But how does Guix know how to build these store outputs in the first place? That's where derivations come in. # `.drv` Files You've probably seen these being printed by the Guix CLI now and again. Derivations, represented in the daemon's eyes by `.drv` files, contain instructions for building store items. We can retrieve the paths of these `.drv` files with the `guix build --derivations` command: ``` $ guix build --derivations irssi /gnu/store/zcgmhac8r4kdj2s6bcvcmhh4k35qvihx-irssi-1.4.3.drv ``` `guix build` can actually also accept derivation paths as an argument, in lieu of a package, like so: ``` $ guix build /gnu/store/zcgmhac8r4kdj2s6bcvcmhh4k35qvihx-irssi-1.4.3.drv /gnu/store/v5pd69j3hjs1fck4b5p9hd91wc8yf5qx-irssi-1.4.3 ``` Let's look inside this derivation file. ``` Derive([("out","/gnu/store/v5pd69j3hjs1fck4b5p9hd91wc8yf5qx-irssi-1.4.3",""= ,"")],[("/gnu/store/9mv9xg4kyj4h1cvsgrw7b9x34y8yppph-glib-2.70.2.drv",["out= "]),("/gnu/store/baqpbl4wck7nkxrbyc9nlhma7kq5dyfl-guile-2.0.14.drv",["out"]= ),("/gnu/store/bfirgq65ndhf63nn4q6vlkbha9zd931q-openssl-1.1.1l.drv",["out"]= ),("/gnu/store/gjwpqzvfhz13shix6a6cs2hjc18pj7wy-module-import-compiled.drv"= ,["out"]),("/gnu/store/ij8651x4yh53hhcn6qw2644nhh2s8kcn-glib-2.70.2.drv",["= out"]),("/gnu/store/jg2vv6yc2yqzi3qzs82dxvqmi5k21lhy-irssi-1.4.3.drv",["out= "]),("/gnu/store/qggpjl9g6ic3cq09qrwkm0dfsdjf7pyr-glibc-utf8-locales-2.33.d= rv",["out"]),("/gnu/store/zafabw13yyhz93jwrcz7axak1kn1f2cx-openssl-1.1.1s.d= rv",["out"])],["/gnu/store/af18nrrsk98c5a71h3fifnxg1zi5mx7y-module-import",= "/gnu/store/qnrwmby5cwqdqxyiv1ga6azvakmdvgl7-irssi-1.4.3-builder"],"x86_64-= linux","/gnu/store/hnr4r2d0h0xarx52i6jq9gvsrlc3q81a-guile-2.0.14/bin/guile"= ,["--no-auto-compile","-L","/gnu/store/af18nrrsk98c5a71h3fifnxg1zi5mx7y-mod= ule-import","-C","/gnu/store/6rkkvvb7pl1l9ng8vvywvwf357vhm3va-module-import= -compiled","/gnu/store/qnrwmby5cwqdqxyiv1ga6azvakmdvgl7-irssi-1.4.3-builder= "],[("allowSubstitutes","0"),("guix properties","((type . graft) (graft (co= unt . 2)))"),("out","/gnu/store/v5pd69j3hjs1fck4b5p9hd91wc8yf5qx-irssi-1.4.= 3"),("preferLocalBuild","1")]) ``` It's... not exactly human-readable. We could try to format it and break it down, but it'd still be pretty hard to understand, since `.drv` files contain no labels for the "arguments" or any other human-readable indicator= s. Instead, we're going to explore derivations in a Guile REPL. # Exploring Guix Interactively Before we continue, we'll want to start a REPL, so that we can try out the Guix Guile API interactively. To run a REPL in the terminal, simply [call `guix repl`](https://guix.gnu.org/manual/devel/en/html_node/Using-Gui= x-Interactively.html). If you're using Emacs, you can instead install [Geiser](https://nongnu.org/= geiser), which provides a comfortable Emacs UI for various Lisp REPLs, invoke `guix repl --listen=3Dtcp:37146 &`, and type `M-x geiser-connect RET RET RE= T` to connect to the running Guile instance. There are a few Guix modules we'll need. Run this Scheme code to import them: ```scheme (use-modules (guix derivations) (guix gexp) (guix packages) (guix store) (gnu packages glib) (gnu packages irc)) ``` We now have access to the store, G-expression, package, and derivation APIs, along with the `irssi` and `glib` `` objects. # Creating a `` The Guix API for derivations revolves around the `` record, which is the Scheme representation of that whole block of text surrounded b= y `Derive(...)`. If we look in `guix/derivations.scm`, we can see that it's defined like this: ```scheme (define-immutable-record-type (make-derivation outputs inputs sources system builder args env-vars file-name) derivation? (outputs derivation-outputs) ; list of name/ pai= rs (inputs derivation-inputs) ; list of (sources derivation-sources) ; list of store paths (system derivation-system) ; string (builder derivation-builder) ; store path (args derivation-builder-arguments) ; list of strings (env-vars derivation-builder-environment-vars) ; list of name/value pair= s (file-name derivation-file-name)) ; the .drv file name ``` With the exception of `file-name`, each of those fields corresponds to an "argument" in the `Derive(...)` form. Before we can examine them, though, we need to figure out how to _lower_ that `irssi` `` object into a derivation. The procedure we use to turn a high-level object like `` into a derivation is called `lower-object`; more on that in a future post. However, this doesn't produce a derivation: ```scheme (pk (lower-object irssi)) ;;; (#) ``` `pk` is an abbreviation for the procedure `peek`, which takes the given object, writes a representation of it to the output, and returns it. It's especially handy when you want to view an intermediate value in a complex expression. The returned object is a procedure that needs to be evaluated in the context of a store connection. We do this by first using `with-store` to connect to the store and bind the connection to a name, then wrapping the `lower-object` call with `run-with-store`: ```scheme (define irssi-drv (pk (with-store %store (run-with-store %store (lower-object irssi))))) ;;; (# /gnu/store/v5pd69j3hjs1fck4b5p9hd91wc8yf5qx-irssi-1.4.3 7fe1902b614= 0>) (define glib-drv (pk (with-store %store (run-with-store %store (lower-object glib))))) ;;; (# /gnu/store/lp7k9ygvpwxgxjvmf8bix8d2aar0azr7-glib-2.70.2-bin /gnu/st= ore/22mkp8cr6rxg6w8br9q8dbymf51b44m8-glib-2.70.2-debug /gnu/store/a6qb5arvi= r4vm1zlkp4chnl7d8qzzd7x-glib-2.70.2 /gnu/store/y4ak268dcdwkc6lmqfk9g1dgk2jr= 9i34-glib-2.70.2-static 7fe17ca13b90>) ``` And we have liftoff! Now we've got two `` records to play with. # Exploring `` The first "argument" in the `.drv` file is `outputs`, which tells the Guix daemon about the outputs that this build can produce: ```scheme (define irssi-outputs (pk (derivation-outputs irssi-drv))) ;;; ((("out" . #< path: "/gnu/store/v5pd69j3hjs1fck4b5p9= hd91wc8yf5qx-irssi-1.4.3" hash-algo: #f hash: #f recursive?: #f>))) (pk (assoc-ref irssi-outputs "out")) (define glib-outputs (pk (derivation-outputs glib-drv))) ;;; ((("bin" . #< path: "/gnu/store/lp7k9ygvpwxgxjvmf8bi= x8d2aar0azr7-glib-2.70.2-bin" hash-algo: #f hash: #f recursive?: #f>) ("deb= ug" . #< path: "/gnu/store/22mkp8cr6rxg6w8br9q8dbymf51b4= 4m8-glib-2.70.2-debug" hash-algo: #f hash: #f recursive?: #f>) ("out" . #<<= derivation-output> path: "/gnu/store/a6qb5arvir4vm1zlkp4chnl7d8qzzd7x-glib-= 2.70.2" hash-algo: #f hash: #f recursive?: #f>) ("static" . #< path: "/gnu/store/y4ak268dcdwkc6lmqfk9g1dgk2jr9i34-glib-2.70.2-stati= c" hash-algo: #f hash: #f recursive?: #f>))) (pk (assoc-ref glib-outputs "bin")) ;;; (#< path: "/gnu/store/lp7k9ygvpwxgxjvmf8bix8d2aar0az= r7-glib-2.70.2-bin" hash-algo: #f hash: #f recursive?: #f>) ``` It's a simple association list mapping output names to `= ` records, and it's equivalent to the first "argument" in the `.drv` file: ``` [ ("out", "/gnu/store/v5pd69j3hjs1fck4b5p9hd91wc8yf5qx-irssi-1.4.3", "", ""= ) ] ``` The `hash-algo` and `hash` fields are for storing the content hash and the algorithm used with that hash for what we term a _fixed-output derivation_, which is essentially a derivation where we know what the hash of the conten= t will be in advance. For instance, `origin`s produce fixed-output derivatio= ns: ```scheme (define irssi-src-drv (pk (with-store %store (run-with-store %store (lower-object (package-source irssi)))))) ;;; (# /gnu/store/cflbi4nbak0v9xbyc43lamzl4a539hhb-irssi-1.4.3.tar.= xz 7fe17b3c8d70>) (define irssi-src-outputs (pk (derivation-outputs irssi-src-drv))) ;;; ((("out" . #< path: "/gnu/store/cflbi4nbak0v9xbyc43l= amzl4a539hhb-irssi-1.4.3.tar.xz" hash-algo: sha256 hash: #vu8(185 63 113 82= 35 163 34 230 127 66 182 26 8 165 18 174 41 227 75 212 165 61 127 34 55 10= 2 102 10 170 90 4 52) recursive?: #f>))) =20 (pk (assoc-ref irssi-src-outputs "out")) ;;; (#< path: "/gnu/store/cflbi4nbak0v9xbyc43lamzl4a539h= hb-irssi-1.4.3.tar.xz" hash-algo: sha256 hash: #vu8(185 63 113 82 35 163 34= 230 127 66 182 26 8 165 18 174 41 227 75 212 165 61 127 34 55 102 102 10 1= 70 90 4 52) recursive?: #f>) ``` Note how the `hash` and `hash-algo` now have values. Perceptive readers may note that the `` has four fields, whereas the tuple in the `.drv` file only has three (minus the label). If we read the source for `write-derivation`, we can see that the `recursive?` field is serialised by prefixing the `hash-algo` with `r:` if it's true: ```scheme ;;; guix/derivations.scm:630:2 (define (write-output output port) (match output ((name . ($ path hash-algo hash recursive?)) (write-tuple (list name path (if hash-algo (string-append (if recursive? "r:" "") (symbol->string hash-algo)) "") (or (and=3D> hash bytevector->base16-string) "")) write-escaped-string port)))) ``` The purpose of `recursive?` is difficult to explain, and is out of scope fo= r this post. The next field is `inputs`, which corresponds to, you guessed it, the second pseudo-"argument" in the `.drv` file format: ``` [ ("/gnu/store/9mv9xg4kyj4h1cvsgrw7b9x34y8yppph-glib-2.70.2.drv", ["out"]), ("/gnu/store/baqpbl4wck7nkxrbyc9nlhma7kq5dyfl-guile-2.0.14.drv", ["out"])= , ("/gnu/store/bfirgq65ndhf63nn4q6vlkbha9zd931q-openssl-1.1.1l.drv", ["out"= ]), ("/gnu/store/gjwpqzvfhz13shix6a6cs2hjc18pj7wy-module-import-compiled.drv"= , ["out"]), ("/gnu/store/ij8651x4yh53hhcn6qw2644nhh2s8kcn-glib-2.70.2.drv", ["out"]), ("/gnu/store/jg2vv6yc2yqzi3qzs82dxvqmi5k21lhy-irssi-1.4.3.drv", ["out"]), ("/gnu/store/qggpjl9g6ic3cq09qrwkm0dfsdjf7pyr-glibc-utf8-locales-2.33.drv= ", ["out"]), ("/gnu/store/zafabw13yyhz93jwrcz7axak1kn1f2cx-openssl-1.1.1s.drv", ["out"= ]) ] ``` Here, each tuple specifies a derivation that needs to be built before this derivation can be built, and the outputs of the derivation that the build process of this derivation uses. Let's grab us the Scheme equivalent: ```scheme (define irssi-inputs (pk (derivation-inputs irssi-drv))) ;;; [a fairly large amount of output] (pk (car irssi-inputs)) ;;; (#< drv: # /gnu/store/2jj2mxn6wfrcw7i85nywk71mmqbnhz= ps-glib-2.70.2 7fe1902b6640> sub-derivations: ("out")>) ``` Unlike `derivation-outputs`, `derivation-inputs` maps 1:1 to the `.drv` form; the `drv` field is a `` to be built, and the `sub-derivations` field is a list of outputs. The other pseudo-"arguments" are pretty simple; none of them involve new records. The third is `derivation-sources`, which contains a list of all store items used in the build which aren't themselves built using derivations, whereas `derivation-inputs` contains the dependencies which are. This list usually just contains the path to the Guile _build script_ that realises the store items when run, which we'll examine in a later post, and the path to a directory containing extra modules to add to the build script= 's `%load-path`, called `/gnu/store/...-module-import`. The next "argument" is self-explanatory: `derivation-system`, which specifi= es the Nix system we're building for. Next is `derivation-builder`, pointing = to the `guile` executable that runs the script; and the second-to-last is `derivation-args`, which is a list of arguments to pass to `derivation-buil= der`. Note how we use `-L` and `-C` to extend the Guile `%load-path` and `%load-compiled-path` to include the `module-import` and `module-import-com= piled` directories: ```scheme (pk (derivation-system irssi-drv)) ;;; ("x86_64-linux") (pk (derivation-builder irrsi-drv)) ;;; ("/gnu/store/hnr4r2d0h0xarx52i6jq9gvsrlc3q81a-guile-2.0.14/bin/guile") (pk (derivation-builder-arguments irrsi-drv)) ;;; (("--no-auto-compile" "-L" "/gnu/store/af18nrrsk98c5a71h3fifnxg1zi5mx7y= -module-import" "-C" "/gnu/store/6rkkvvb7pl1l9ng8vvywvwf357vhm3va-module-im= port-compiled" "/gnu/store/qnrwmby5cwqdqxyiv1ga6azvakmdvgl7-irssi-1.4.3-bui= lder")) ``` The final "argument" contains a list of environment variables to set before we start the build process: ```scheme (pk (derivation-builder-environment-vars irssi-drv)) ;;; ((("allowSubstitutes" . "0") ("guix properties" . "((type . graft) (gra= ft (count . 2)))") ("out" . "/gnu/store/v5pd69j3hjs1fck4b5p9hd91wc8yf5qx-ir= ssi-1.4.3") ("preferLocalBuild" . "1"))) ``` Obviously, the last record field, `derivation-file-name`, simply allows you= to retrieve the path to the `.drv` file in Scheme, and so isn't represented in a serialised derivation. Speaking of serialisation, to convert between = the `.drv` text format and the Scheme `` record, you can use `write-derivation`, `read-derivation`, and `read-derivation-from-file`. # Conclusion Derivations are one of Guix's most important concepts, but are fairly easy = to understand once you get past the obtuse `.drv` file format. They provide t= he Guix daemon with the initial instructions that it uses to build store items like packages, origins, and other file-likes such as `computed-file` and `local-file`, which will be discussed in a future post! #### About GNU Guix [GNU Guix](https://guix.gnu.org) is a transactional package manager and an advanced distribution of the GNU system that [respects user freedom](https://www.gnu.org/distros/free-system-distribution-guidelines.ht= ml). Guix can be used on top of any system running the Hurd or the Linux kernel, or it can be used as a standalone operating system distribution for i686, x86_64, ARMv7, AArch64 and POWER9 machines. In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and garbage collection. When used as a standalone GNU/Linux distribution, Guix offers a declarative, stateless approach to operating system configuration management. Guix is highly customizable and hackable through [Guile](https://www.gnu.org/software/guile) programming interfaces and extensions to the [Scheme](http://schemers.org) language. --7f149c2c581bc3c0015b90a4e544ea0729385b4245535dbd0b2c74be6f8e Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEE6Vh10NblKE5doNlW7ImHg/nqI20FAmOSK/wACgkQ7ImHg/nq I22RpgwA4EsdQxvcWz1nemxVXj+iEAUBscGyXM78/7BK7tsMH3N+e5GarCtT5Lzz irKSGiVnwSPzO2RGL6L7gKSu0+woPYy6sfr5f+5f7mG6aN7eqqWo+9gMlpmUaWBk 3CJnBte+DR/144mmg6wEE8jHoDGj/peRAxYyOqL7/GVSPM0BxFSE0M7i788n8KUY Zdzqv7elbt4jRN7YydXLq9ej6p26Sm7mW7SHMpYSJrUahjBwKsnIOMpZDlUe5DMm 4Vta0eblWC6fojghG4m+lNHIBuIo6N5bQGDiipakNNiJoBbUkChT/5NEPn9MK/2N Njge5cgrIee3xBDRhZjDI/fQEay/3MoebcsYb5gSXglqZCOik3wWQVAgjrtXYUoK bN05nBIhh8/Jz4nc//Yke/TG1dmikzXvyuMicVs3XSbKhxdIuwis0hJmhnr5vYM0 2yDYRhVpN3EWLo8R1l/u8Ywjjz251aDn+GSh4wstFavKdnqE6BTLbEvVhkKmlRkM acxU7VkQ =soj9 -----END PGP SIGNATURE----- --7f149c2c581bc3c0015b90a4e544ea0729385b4245535dbd0b2c74be6f8e--