5 @setfilename guix-cookbook.info
6 @documentencoding UTF-8
7 @settitle GNU Guix Cookbook
11 Copyright @copyright{} 2019 Ricardo Wurmus@*
12 Copyright @copyright{} 2019 Efraim Flashner@*
13 Copyright @copyright{} 2019 Pierre Neidhardt@*
14 Copyright @copyright{} 2020 Oleg Pykhalov@*
16 Permission is granted to copy, distribute and/or modify this document
17 under the terms of the GNU Free Documentation License, Version 1.3 or
18 any later version published by the Free Software Foundation; with no
19 Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
20 copy of the license is included in the section entitled ``GNU Free
21 Documentation License''.
24 @dircategory System administration
26 * Guix cookbook: (guix-cookbook). Tutorials and examples for GNU Guix.
30 @title GNU Guix Cookbook
31 @subtitle Tutorials and examples for using the GNU Guix Functional Package Manager
32 @author The GNU Guix Developers
35 @vskip 0pt plus 1filll
42 @c *********************************************************************
44 @top GNU Guix Cookbook
46 This document presents tutorials and detailed examples for GNU@tie{}Guix, a
47 functional package management tool written for the GNU system. Please
48 @pxref{Top,,, guix, GNU Guix reference manual} for details about the system,
49 its API, and related concepts.
51 @c TRANSLATORS: You can replace the following paragraph with information on
52 @c how to join your own translation team and how to report issues with the
54 If you would like to translate this document in your native language, consider
55 joining the @uref{https://translationproject.org/domain/guix-cookbook.html,
59 * Scheme tutorials:: Meet your new favorite language!
60 * Packaging:: Packaging tutorials
61 * System Configuration:: Customizing the GNU System
62 * Advanced package management:: Power to the users!
64 * Acknowledgments:: Thanks!
65 * GNU Free Documentation License:: The license of this document.
66 * Concept Index:: Concepts.
69 --- The Detailed Node Listing ---
73 * A Scheme Crash Course:: Learn the basics of Scheme
77 * Packaging Tutorial:: Let's add a package to Guix!
81 * Customizing the Kernel:: Creating and using a custom Linux kernel
87 @c *********************************************************************
88 @node Scheme tutorials
89 @chapter Scheme tutorials
91 GNU@tie{}Guix is written in the general purpose programming language Scheme,
92 and many of its features can be accessed and manipulated programmatically.
93 You can use Scheme to generate package definitions, to modify them, to build
94 them, to deploy whole operating systems, etc.
96 Knowing the basics of how to program in Scheme will unlock many of the
97 advanced features Guix provides --- and you don't even need to be an
98 experienced programmer to use them!
102 @node A Scheme Crash Course
103 @section A Scheme Crash Course
105 @cindex Scheme, crash course
107 Guix uses the Guile implementation of Scheme. To start playing with the
108 language, install it with @code{guix install guile} and start a
109 @uref{https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop,
110 REPL} by running @code{guile} from the command line.
112 Alternatively you can also run @code{guix environment --ad-hoc guile -- guile}
113 if you'd rather not have Guile installed in your user profile.
115 In the following examples, lines show what you would type at the REPL;
116 lines starting with ``@result{}'' show evaluation results, while lines
117 starting with ``@print{}'' show things that get printed. @xref{Using Guile
118 Interactively,,, guile, GNU Guile Reference Manual}), for more details on the
123 Scheme syntax boils down to a tree of expressions (or @emph{s-expression} in
124 Lisp lingo). An expression can be a literal such as numbers and strings, or a
125 compound which is a parenthesized list of compounds and literals. @code{#t}
126 and @code{#f} stand for the Booleans ``true'' and ``false'', respectively.
128 Examples of valid expressions:
132 @result{} "Hello World!"
137 (display (string-append "Hello " "Guix" "\n"))
139 @result{} #<unspecified>
143 This last example is a function call nested in another function call. When a
144 parenthesized expression is evaluated, the first term is the function and the
145 rest are the arguments passed to the function. Every function returns the
146 last evaluated expression as its return value.
149 Anonymous functions are declared with the @code{lambda} term:
153 @result{} #<procedure 120e348 at <unknown port>:24:0 (x)>
156 The above procedure returns the square of its argument. Since everything is
157 an expression, the @code{lambda} expression returns an anonymous procedure,
158 which can in turn be applied to an argument:
161 ((lambda (x) (* x x)) 3)
166 Anything can be assigned a global name with @code{define}:
170 (define square (lambda (x) (* x x)))
176 Procedures can be defined more concisely with the following syntax:
179 (define (square x) (* x x))
183 A list structure can be created with the @code{list} procedure:
191 The @dfn{quote} disables evaluation of a parenthesized expression: the
192 first term is not called over the other terms (@pxref{Expression Syntax,
193 quote,, guile, GNU Guile Reference Manual}). Thus it effectively
194 returns a list of terms.
197 '(display (string-append "Hello " "Guix" "\n"))
198 @result{} (display (string-append "Hello " "Guix" "\n"))
205 The @dfn{quasiquote} disables evaluation of a parenthesized expression
206 until @dfn{unquote} (a comma) re-enables it. Thus it provides us with
207 fine-grained control over what is evaluated and what is not.
210 `(2 a 5 7 (2 ,a 5 ,(+ a 4)))
211 @result{} (2 a 5 7 (2 3 5 7))
214 Note that the above result is a list of mixed elements: numbers, symbols (here
215 @code{a}) and the last element is a list itself.
218 Multiple variables can be named locally with @code{let} (@pxref{Local
219 Bindings,,, guile, GNU Guile Reference Manual}):
232 @error{} In procedure module-lookup: Unbound variable: y
235 Use @code{let*} to allow later variable declarations to refer to earlier
246 The keyword syntax is @code{#:}; it is used to create unique identifiers.
247 @pxref{Keywords,,, guile, GNU Guile Reference Manual}.
250 The percentage @code{%} is typically used for read-only global variables in
251 the build stage. Note that it is merely a convention, like @code{_} in C.
252 Scheme treats @code{%} exactly the same as any other letter.
255 Modules are created with @code{define-module} (@pxref{Creating Guile
256 Modules,,, guile, GNU Guile Reference Manual}). For instance
259 (define-module (guix build-system ruby)
260 #:use-module (guix store)
265 defines the module @code{guix build-system ruby} which must be located in
266 @file{guix/build-system/ruby.scm} somewhere in the Guile load path. It
267 depends on the @code{(guix store)} module and it exports two variables,
268 @code{ruby-build} and @code{ruby-build-system}.
271 For a more detailed introduction, check out
272 @uref{http://www.troubleshooters.com/codecorn/scheme_guile/hello.htm, Scheme
273 at a Glance}, by Steve Litt.
275 One of the reference Scheme books is the seminal ``Structure and
276 Interpretation of Computer Programs'', by Harold Abelson and Gerald Jay
277 Sussman, with Julie Sussman. You'll find a
278 @uref{https://mitpress.mit.edu/sites/default/files/sicp/index.html, free copy
279 online}, together with
280 @uref{https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video-lectures/,
281 videos of the lectures by the authors}. The book is available in Texinfo
282 format as the @code{sicp} Guix package. Go ahead, run @code{guix install
283 sicp} and start reading with @code{info sicp} (@pxref{,,, sicp, Structure and Interpretation of Computer Programs}).
284 An @uref{https://sarabander.github.io/sicp/, unofficial ebook is also
287 You'll find more books, tutorials and other resources at
288 @url{https://schemers.org/}.
291 @c *********************************************************************
297 This chapter is dedicated to teaching you how to add packages to the
298 collection of packages that come with GNU Guix. This involves writing package
299 definitions in Guile Scheme, organizing them in package modules, and building
303 * Packaging Tutorial:: A tutorial on how to add packages to Guix.
306 @node Packaging Tutorial
307 @section Packaging Tutorial
309 GNU Guix stands out as the @emph{hackable} package manager, mostly because it
310 uses @uref{https://www.gnu.org/software/guile/, GNU Guile}, a powerful
311 high-level programming language, one of the
312 @uref{https://en.wikipedia.org/wiki/Scheme_%28programming_language%29, Scheme}
314 @uref{https://en.wikipedia.org/wiki/Lisp_%28programming_language%29, Lisp family}.
316 Package definitions are also written in Scheme, which empowers Guix in some
317 very unique ways, unlike most other package managers that use shell scripts or
322 Use functions, structures, macros and all of Scheme expressiveness for your
326 Inheritance makes it easy to customize a package by inheriting from it and
327 modifying only what is needed.
330 Batch processing: the whole package collection can be parsed, filtered and
331 processed. Building a headless server with all graphical interfaces stripped
332 out? It's possible. Want to rebuild everything from source using specific
333 compiler optimization flags? Pass the @code{#:make-flags "..."} argument to
334 the list of packages. It wouldn't be a stretch to think
335 @uref{https://wiki.gentoo.org/wiki/USE_flag, Gentoo USE flags} here, but this
336 goes even further: the changes don't have to be thought out beforehand by the
337 packager, they can be @emph{programmed} by the user!
340 The following tutorial covers all the basics around package creation with Guix.
341 It does not assume much knowledge of the Guix system nor of the Lisp language.
342 The reader is only expected to be familiar with the command line and to have some
343 basic programming knowledge.
345 @node A ``Hello World'' package
346 @subsection A ``Hello World'' package
348 The ``Defining Packages'' section of the manual introduces the basics of Guix
349 packaging (@pxref{Defining Packages,,, guix, GNU Guix Reference Manual}). In
350 the following section, we will partly go over those basics again.
352 GNU@tie{}Hello is a dummy project that serves as an idiomatic example for
353 packaging. It uses the GNU build system (@code{./configure && make && make
354 install}). Guix already provides a package definition which is a perfect
355 example to start with. You can look up its declaration with @code{guix edit
356 hello} from the command line. Let's see how it looks:
365 (uri (string-append "mirror://gnu/hello/hello-" version
369 "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
370 (build-system gnu-build-system)
371 (synopsis "Hello, GNU world: An example GNU package")
373 "GNU Hello prints the message \"Hello, world!\" and then exits. It
374 serves as an example of standard GNU coding practices. As such, it supports
375 command-line arguments, multiple languages, and so on.")
376 (home-page "https://www.gnu.org/software/hello/")
380 As you can see, most of it is rather straightforward. But let's review the
385 The project name. Using Scheme conventions, we prefer to keep it
386 lower case, without underscore and using dash-separated words.
389 This field contains a description of the source code origin. The
390 @code{origin} record contains these fields:
393 @item The method, here @code{url-fetch} to download via HTTP/FTP, but other methods
394 exist, such as @code{git-fetch} for Git repositories.
395 @item The URI, which is typically some @code{https://} location for @code{url-fetch}. Here
396 the special `mirror://gnu` refers to a set of well known locations, all of
397 which can be used by Guix to fetch the source, should some of them fail.
398 @item The @code{sha256} checksum of the requested file. This is essential to ensure
399 the source is not corrupted. Note that Guix works with base32 strings,
400 hence the call to the @code{base32} function.
405 This is where the power of abstraction provided by the Scheme language really
406 shines: in this case, the @code{gnu-build-system} abstracts away the famous
407 @code{./configure && make && make install} shell invocations. Other build
408 systems include the @code{trivial-build-system} which does not do anything and
409 requires from the packager to program all the build steps, the
410 @code{python-build-system}, the @code{emacs-build-system}, and many more
411 (@pxref{Build Systems,,, guix, GNU Guix Reference Manual}).
414 It should be a concise summary of what the package does. For many packages a
415 tagline from the project's home page can be used as the synopsis.
418 Same as for the synopsis, it's fine to re-use the project description from the
419 homepage. Note that Guix uses Texinfo syntax.
422 Use HTTPS if available.
425 See @code{guix/licenses.scm} in the project source for a full list of
429 Time to build our first package! Nothing fancy here for now: we will stick to a
430 dummy @code{my-hello}, a copy of the above declaration.
432 As with the ritualistic ``Hello World'' taught with most programming languages,
433 this will possibly be the most ``manual'' approach. We will work out an ideal
434 setup later; for now we will go the simplest route.
436 Save the following to a file @file{my-hello.scm}.
439 (use-modules (guix packages)
441 (guix build-system gnu)
449 (uri (string-append "mirror://gnu/hello/hello-" version
453 "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
454 (build-system gnu-build-system)
455 (synopsis "Hello, Guix world: An example custom Guix package")
457 "GNU Hello prints the message \"Hello, world!\" and then exits. It
458 serves as an example of standard GNU coding practices. As such, it supports
459 command-line arguments, multiple languages, and so on.")
460 (home-page "https://www.gnu.org/software/hello/")
464 We will explain the extra code in a moment.
466 Feel free to play with the different values of the various fields. If you
467 change the source, you'll need to update the checksum. Indeed, Guix refuses to
468 build anything if the given checksum does not match the computed checksum of the
469 source code. To obtain the correct checksum of the package declaration, we
470 need to download the source, compute the sha256 checksum and convert it to
473 Thankfully, Guix can automate this task for us; all we need is to provide the
476 @c TRANSLATORS: This is example shell output.
478 $ guix download mirror://gnu/hello/hello-2.10.tar.gz
480 Starting download of /tmp/guix-file.JLYgL7
481 From https://ftpmirror.gnu.org/gnu/hello/hello-2.10.tar.gz...
482 following redirection to `https://mirror.ibcp.fr/pub/gnu/hello/hello-2.10.tar.gz'...
483 …10.tar.gz 709KiB 2.5MiB/s 00:00 [##################] 100.0%
484 /gnu/store/hbdalsf5lpf01x4dcknwx6xbn6n5km6k-hello-2.10.tar.gz
485 0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i
488 In this specific case the output tells us which mirror was chosen.
489 If the result of the above command is not the same as in the above snippet,
490 update your @code{my-hello} declaration accordingly.
492 Note that GNU package tarballs come with an OpenPGP signature, so you
493 should definitely check the signature of this tarball with `gpg` to
494 authenticate it before going further:
496 @c TRANSLATORS: This is example shell output.
498 $ guix download mirror://gnu/hello/hello-2.10.tar.gz.sig
500 Starting download of /tmp/guix-file.03tFfb
501 From https://ftpmirror.gnu.org/gnu/hello/hello-2.10.tar.gz.sig...
502 following redirection to `https://ftp.igh.cnrs.fr/pub/gnu/hello/hello-2.10.tar.gz.sig'...
503 ….tar.gz.sig 819B 1.2MiB/s 00:00 [##################] 100.0%
504 /gnu/store/rzs8wba9ka7grrmgcpfyxvs58mly0sx6-hello-2.10.tar.gz.sig
505 0q0v86n3y38z17rl146gdakw9xc4mcscpk8dscs412j22glrv9jf
506 $ gpg --verify /gnu/store/rzs8wba9ka7grrmgcpfyxvs58mly0sx6-hello-2.10.tar.gz.sig /gnu/store/hbdalsf5lpf01x4dcknwx6xbn6n5km6k-hello-2.10.tar.gz
507 gpg: Signature made Sun 16 Nov 2014 01:08:37 PM CET
508 gpg: using RSA key A9553245FDE9B739
509 gpg: Good signature from "Sami Kerola <kerolasa@@iki.fi>" [unknown]
510 gpg: aka "Sami Kerola (http://www.iki.fi/kerolasa/) <kerolasa@@iki.fi>" [unknown]
511 gpg: WARNING: This key is not certified with a trusted signature!
512 gpg: There is no indication that the signature belongs to the owner.
513 Primary key fingerprint: 8ED3 96E3 7E38 D471 A005 30D3 A955 3245 FDE9 B739
516 You can then happily run
518 @c TRANSLATORS: Do not translate this command
520 $ guix package --install-from-file=my-hello.scm
523 You should now have @code{my-hello} in your profile!
525 @c TRANSLATORS: Do not translate this command
527 $ guix package --list-installed=my-hello
529 /gnu/store/f1db2mfm8syb8qvc357c53slbvf1g9m9-my-hello-2.10
532 We've gone as far as we could without any knowledge of Scheme. Before moving
533 on to more complex packages, now is the right time to brush up on your Scheme
534 knowledge. @pxref{A Scheme Crash Course} to get up to speed.
539 In the rest of this chapter we will rely on some basic Scheme
540 programming knowledge. Now let's detail the different possible setups
541 for working on Guix packages.
543 There are several ways to set up a Guix packaging environment.
545 We recommend you work directly on the Guix source checkout since it makes it
546 easier for everyone to contribute to the project.
548 But first, let's look at other possibilities.
551 @subsubsection Local file
553 This is what we previously did with @samp{my-hello}. With the Scheme basics we've
554 covered, we are now able to explain the leading chunks. As stated in @code{guix
558 -f, --install-from-file=FILE
559 install the package that the code within FILE
563 Thus the last expression @emph{must} return a package, which is the case in our
566 The @code{use-modules} expression tells which of the modules we need in the file.
567 Modules are a collection of values and procedures. They are commonly called
568 ``libraries'' or ``packages'' in other programming languages.
570 @node @samp{GUIX_PACKAGE_PATH}
571 @subsubsection @samp{GUIX_PACKAGE_PATH}
573 @emph{Note: Starting from Guix 0.16, the more flexible Guix @dfn{channels} are the
574 preferred way and supersede @samp{GUIX_PACKAGE_PATH}. See next section.}
576 It can be tedious to specify the file from the command line instead of simply
577 calling @code{guix package --install my-hello} as you would do with the official
580 Guix makes it possible to streamline the process by adding as many ``package
581 declaration directories'' as you want.
583 Create a directory, say @samp{~./guix-packages} and add it to the @samp{GUIX_PACKAGE_PATH}
584 environment variable:
587 $ mkdir ~/guix-packages
588 $ export GUIX_PACKAGE_PATH=~/guix-packages
591 To add several directories, separate them with a colon (@code{:}).
593 Our previous @samp{my-hello} needs some adjustments though:
596 (define-module (my-hello)
597 #:use-module (guix licenses)
598 #:use-module (guix packages)
599 #:use-module (guix build-system gnu)
600 #:use-module (guix download))
602 (define-public my-hello
608 (uri (string-append "mirror://gnu/hello/hello-" version
612 "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
613 (build-system gnu-build-system)
614 (synopsis "Hello, Guix world: An example custom Guix package")
616 "GNU Hello prints the message \"Hello, world!\" and then exits. It
617 serves as an example of standard GNU coding practices. As such, it supports
618 command-line arguments, multiple languages, and so on.")
619 (home-page "https://www.gnu.org/software/hello/")
623 Note that we have assigned the package value to an exported variable name with
624 @code{define-public}. This is effectively assigning the package to the @code{my-hello}
625 variable so that it can be referenced, among other as dependency of other
628 If you use @code{guix package --install-from-file=my-hello.scm} on the above file, it
629 will fail because the last expression, @code{define-public}, does not return a
630 package. If you want to use @code{define-public} in this use-case nonetheless, make
631 sure the file ends with an evaluation of @code{my-hello}:
635 (define-public my-hello
642 This last example is not very typical.
644 Now @samp{my-hello} should be part of the package collection like all other official
645 packages. You can verify this with:
648 $ guix package --show=my-hello
652 @subsubsection Guix channels
654 Guix 0.16 features channels, which is very similar to @samp{GUIX_PACKAGE_PATH} but
655 provides better integration and provenance tracking. Channels are not
656 necessarily local, they can be maintained as a public Git repository for
657 instance. Of course, several channels can be used at the same time.
659 @xref{Channels,,, guix, GNU Guix Reference Manual} for setup details.
661 @node Direct checkout hacking
662 @subsubsection Direct checkout hacking
664 Working directly on the Guix project is recommended: it reduces the friction
665 when the time comes to submit your changes upstream to let the community benefit
668 Unlike most software distributions, the Guix repository holds in one place both
669 the tooling (including the package manager) and the package definitions. This
670 choice was made so that it would give developers the flexibility to modify the
671 API without breakage by updating all packages at the same time. This reduces
674 Check out the official @uref{https://git-scm.com/, Git} repository:
677 $ git clone https://git.savannah.gnu.org/git/guix.git
680 In the rest of this article, we use @samp{$GUIX_CHECKOUT} to refer to the location of
684 Follow the instructions in the manual (@pxref{Contributing,,, guix, GNU Guix
685 Reference Manual}) to set up the repository environment.
687 Once ready, you should be able to use the package definitions from the
688 repository environment.
690 Feel free to edit package definitions found in @samp{$GUIX_CHECKOUT/gnu/packages}.
692 The @samp{$GUIX_CHECKOUT/pre-inst-env} script lets you use @samp{guix} over the package
693 collection of the repository (@pxref{Running Guix Before It Is
694 Installed,,, guix, GNU Guix Reference Manual}).
698 Search packages, such as Ruby:
702 $ ./pre-inst-env guix package --list-available=ruby
703 ruby 1.8.7-p374 out gnu/packages/ruby.scm:119:2
704 ruby 2.1.6 out gnu/packages/ruby.scm:91:2
705 ruby 2.2.2 out gnu/packages/ruby.scm:39:2
709 Build a package, here Ruby version 2.1:
712 $ ./pre-inst-env guix build --keep-failed ruby@@2.1
713 /gnu/store/c13v73jxmj2nir2xjqaz5259zywsa9zi-ruby-2.1.6
717 Install it to your user profile:
720 $ ./pre-inst-env guix package --install ruby@@2.1
724 Check for common mistakes:
727 $ ./pre-inst-env guix lint ruby@@2.1
731 Guix strives at maintaining a high packaging standard; when contributing to the
732 Guix project, remember to
736 follow the coding style (@pxref{Coding Style,,, guix, GNU Guix Reference Manual}),
738 and review the check list from the manual (@pxref{Submitting Patches,,, guix, GNU Guix Reference Manual}).
741 Once you are happy with the result, you are welcome to send your contribution to
742 make it part of Guix. This process is also detailed in the manual. (@pxref{Contributing,,, guix, GNU Guix Reference Manual})
745 It's a community effort so the more join in, the better Guix becomes!
747 @node Extended example
748 @subsection Extended example
750 The above ``Hello World'' example is as simple as it goes. Packages can be more
751 complex than that and Guix can handle more advanced scenarios. Let's look at
752 another, more sophisticated package (slightly modified from the source):
755 (define-module (gnu packages version-control)
756 #:use-module ((guix licenses) #:prefix license:)
757 #:use-module (guix utils)
758 #:use-module (guix packages)
759 #:use-module (guix git-download)
760 #:use-module (guix build-system cmake)
761 #:use-module (gnu packages ssh)
762 #:use-module (gnu packages web)
763 #:use-module (gnu packages pkg-config)
764 #:use-module (gnu packages python)
765 #:use-module (gnu packages compression)
766 #:use-module (gnu packages tls))
768 (define-public my-libgit2
769 (let ((commit "e98d0a37c93574d2c6107bf7f31140b548c6a7bf")
773 (version (git-version "0.26.6" revision commit))
777 (url "https://github.com/libgit2/libgit2/")
779 (file-name (git-file-name name version))
782 "17pjvprmdrx4h6bb1hhc98w9qi6ki7yl57f090n9kbhswxqfs7s3"))
783 (patches (search-patches "libgit2-mtime-0.patch"))
784 (modules '((guix build utils)))
786 ;; Remove bundled software.
787 (delete-file-recursively "deps")
789 (build-system cmake-build-system)
790 (outputs '("out" "debug"))
792 `(#:tests? #t ; Run the test suite (this is the default)
793 #:configure-flags '("-DUSE_SHA1DC=ON") ; SHA-1 collision detection
795 (modify-phases %standard-phases
796 (add-after 'unpack 'fix-hardcoded-paths
798 (substitute* "tests/repo/init.c"
799 (("#!/bin/sh") (string-append "#!" (which "sh"))))
800 (substitute* "tests/clar/fs.h"
801 (("/bin/cp") (which "cp"))
802 (("/bin/rm") (which "rm")))
804 ;; Run checks more verbosely.
806 (lambda _ (invoke "./libgit2_clar" "-v" "-Q")))
807 (add-after 'unpack 'make-files-writable-for-tests
808 (lambda _ (for-each make-file-writable (find-files "." ".*")))))))
810 `(("libssh2" ,libssh2)
811 ("http-parser" ,http-parser)
812 ("python" ,python-wrapper)))
814 `(("pkg-config" ,pkg-config)))
816 ;; These two libraries are in 'Requires.private' in libgit2.pc.
817 `(("openssl" ,openssl)
819 (home-page "https://libgit2.github.com/")
820 (synopsis "Library providing Git core methods")
822 "Libgit2 is a portable, pure C implementation of the Git core methods
823 provided as a re-entrant linkable library with a solid API, allowing you to
824 write native speed custom Git applications in any language with bindings.")
825 ;; GPLv2 with linking exception
826 (license license:gpl2))))
829 (In those cases were you only want to tweak a few fields from a package
830 definition, you should rely on inheritance instead of copy-pasting everything.
833 Let's discuss those fields in depth.
835 @subsubsection @code{git-fetch} method
837 Unlike the @code{url-fetch} method, @code{git-fetch} expects a @code{git-reference} which takes
838 a Git repository and a commit. The commit can be any Git reference such as
839 tags, so if the @code{version} is tagged, then it can be used directly. Sometimes
840 the tag is prefixed with a @code{v}, in which case you'd use @code{(commit (string-append
843 To ensure that the source code from the Git repository is stored in a unique
844 directory with a readable name we use @code{(file-name (git-file-name name
847 Note that there is also a @code{git-version} procedure that can be used to derive the
848 version when packaging programs for a specific commit.
850 @subsubsection Snippets
852 Snippets are quoted (i.e. non-evaluated) Scheme code that are a means of patching
853 the source. They are a Guix-y alternative to the traditional @samp{.patch} files.
854 Because of the quote, the code in only evaluated when passed to the Guix daemon
855 for building. There can be as many snippets as needed.
857 Snippets might need additional Guile modules which can be imported from the
858 @code{modules} field.
860 @subsubsection Inputs
862 First, a syntactic comment: See the quasi-quote / comma syntax?
866 `(("pkg-config" ,pkg-config)))
873 (list (list "pkg-config" pkg-config)))
876 You'll mostly see the former because it's shorter.
878 There are 3 different input types. In short:
882 Required for building but not runtime -- installing a package
883 through a substitute won't install these inputs.
885 Installed in the store but not in the profile, as well as being
886 present at build time.
887 @item propagated-inputs
888 Installed in the store and in the profile, as well as
889 being present at build time.
892 @xref{Package Reference,,, guix, GNU Guix Reference Manual} for more details.
894 The distinction between the various inputs is important: if a dependency can be
895 handled as an @emph{input} instead of a @emph{propagated input}, it should be done so, or
896 else it ``pollutes'' the user profile for no good reason.
898 For instance, a user installing a graphical program that depends on a
899 command line tool might only be interested in the graphical part, so there is no
900 need to force the command line tool into the user profile. The dependency is a
901 concern to the package, not to the user. @emph{Inputs} make it possible to handle
902 dependencies without bugging the user by adding undesired executable files (or
903 libraries) to their profile.
905 Same goes for @emph{native-inputs}: once the program is installed, build-time
906 dependencies can be safely garbage-collected.
907 It also matters when a substitute is available, in which case only the @emph{inputs}
908 and @emph{propagated inputs} will be fetched: the @emph{native inputs} are not required to
909 install a package from a substitute.
911 @subsubsection Outputs
913 Just like how a package can have multiple inputs, it can also produce multiple
916 Each output corresponds to a separate directory in the store.
918 The user can choose which output to install; this is useful to save space or
919 to avoid polluting the user profile with unwanted executables or libraries.
921 Output separation is optional. When the @code{outputs} field is left out, the
922 default and only output (the complete package) is referred to as @code{"out"}.
924 Typical separate output names include @code{debug} and @code{doc}.
926 It's advised to separate outputs only when you've shown it's worth it: if the
927 output size is significant (compare with @code{guix size}) or in case the package is
930 @subsubsection Build system arguments
932 The @code{arguments} is a keyword-value list used to configure the build process.
934 The simplest argument @code{#:tests?} can be used to disable the test suite when
935 building the package. This is mostly useful when the package does not feature
936 any test suite. It's strongly recommended to keep the test suite on if there is
939 Another common argument is @code{:make-flags}, which specifies a list of flags to
940 append when running make, as you would from the command line. For instance, the
944 #:make-flags (list (string-append "prefix=" (assoc-ref %outputs "out"))
951 $ make CC=gcc prefix=/gnu/store/...-<out>
954 This sets the C compiler to @code{gcc} and the @code{prefix} variable (the installation
955 directory in Make parlance) to @code{(assoc-ref %outputs "out")}, which is a build-stage
956 global variable pointing to the destination directory in the store (something like
957 @samp{/gnu/store/...-my-libgit2-20180408}).
959 Similarly, it's possible to set the configure flags:
962 #:configure-flags '("-DUSE_SHA1DC=ON")
965 The @code{%build-inputs} variable is also generated in scope. It's an association
966 table that maps the input names to their store directories.
968 The @code{phases} keyword lists the sequential steps of the build system. Typically
969 phases include @code{unpack}, @code{configure}, @code{build}, @code{install} and @code{check}. To know
970 more about those phases, you need to work out the appropriate build system
971 definition in @samp{$GUIX_CHECKOUT/guix/build/gnu-build-system.scm}:
974 (define %standard-phases
975 ;; Standard build phases, as a list of symbol/procedure pairs.
976 (let-syntax ((phases (syntax-rules ()
977 ((_ p ...) `((p . ,p) ...)))))
978 (phases set-SOURCE-DATE-EPOCH set-paths install-locale unpack
981 patch-source-shebangs configure patch-generated-file-shebangs
985 validate-documentation-location
987 patch-dot-desktop-files
988 install-license-files
989 reset-gzip-timestamps
990 compress-documentation)))
996 (add-to-load-path "/path/to/guix/checkout")
997 ,use (guix build gnu-build-system)
998 (map first %standard-phases)
999 @result{} (set-SOURCE-DATE-EPOCH set-paths install-locale unpack bootstrap patch-usr-bin-file patch-source-shebangs configure patch-generated-file-shebangs build check install patch-shebangs strip validate-runpath validate-documentation-location delete-info-dir-file patch-dot-desktop-files install-license-files reset-gzip-timestamps compress-documentation)
1002 If you want to know more about what happens during those phases, consult the
1003 associated procedures.
1005 For instance, as of this writing the definition of @code{unpack} for the GNU build
1009 (define* (unpack #:key source #:allow-other-keys)
1010 "Unpack SOURCE in the working directory, and change directory within the
1011 source. When SOURCE is a directory, copy it in a sub-directory of the current
1013 (if (file-is-directory? source)
1018 ;; Preserve timestamps (set to the Epoch) on the copied tree so that
1019 ;; things work deterministically.
1020 (copy-recursively source "."
1023 (if (string-suffix? ".zip" source)
1024 (invoke "unzip" source)
1025 (invoke "tar" "xvf" source))
1026 (chdir (first-subdirectory "."))))
1030 Note the @code{chdir} call: it changes the working directory to where the source was
1032 Thus every phase following the @code{unpack} will use the source as a working
1033 directory, which is why we can directly work on the source files.
1034 That is to say, unless a later phase changes the working directory to something
1037 We modify the list of @code{%standard-phases} of the build system with the
1038 @code{modify-phases} macro as per the list of specified modifications, which may have
1039 the following forms:
1043 @code{(add-before PHASE NEW-PHASE PROCEDURE)}: Run @code{PROCEDURE} named @code{NEW-PHASE} before @code{PHASE}.
1045 @code{(add-after PHASE NEW-PHASE PROCEDURE)}: Same, but afterwards.
1047 @code{(replace PHASE PROCEDURE)}.
1049 @code{(delete PHASE)}.
1052 The @code{PROCEDURE} supports the keyword arguments @code{inputs} and @code{outputs}. Each
1053 input (whether @emph{native}, @emph{propagated} or not) and output directory is referenced
1054 by their name in those variables. Thus @code{(assoc-ref outputs "out")} is the store
1055 directory of the main output of the package. A phase procedure may look like
1059 (lambda* (#:key inputs outputs #:allow-other-keys)
1060 (let (((bash-directory (assoc-ref inputs "bash"))
1061 (output-directory (assoc-ref outputs "out"))
1062 (doc-directory (assoc-ref outputs "doc"))
1067 The procedure must return @code{#t} on success. It's brittle to rely on the return
1068 value of the last expression used to tweak the phase because there is no
1069 guarantee it would be a @code{#t}. Hence the trailing @code{#t} to ensure the right value
1070 is returned on success.
1072 @subsubsection Code staging
1074 The astute reader may have noticed the quasi-quote and comma syntax in the
1075 argument field. Indeed, the build code in the package declaration should not be
1076 evaluated on the client side, but only when passed to the Guix daemon. This
1077 mechanism of passing code around two running processes is called @uref{https://arxiv.org/abs/1709.00833, code staging}.
1079 @subsubsection Utility functions
1081 When customizing @code{phases}, we often need to write code that mimics the
1082 equivalent system invocations (@code{make}, @code{mkdir}, @code{cp}, etc.) commonly used during
1083 regular ``Unix-style'' installations.
1085 Some like @code{chmod} are native to Guile.
1086 @xref{,,, guile, Guile reference manual} for a complete list.
1088 Guix provides additional helper functions which prove especially handy in the
1089 context of package management.
1091 Some of those functions can be found in
1092 @samp{$GUIX_CHECKOUT/guix/guix/build/utils.scm}. Most of them mirror the behaviour
1093 of the traditional Unix system commands:
1097 Like the @samp{which} system command.
1099 Akin to the @samp{find} system command.
1101 Like @samp{mkdir -p}, which creates all parents as needed.
1103 Similar to @samp{install} when installing a file to a (possibly
1104 non-existing) directory. Guile has @code{copy-file} which works
1106 @item copy-recursively
1108 @item delete-file-recursively
1111 Run an executable. This should be used instead of @code{system*}.
1112 @item with-directory-excursion
1113 Run the body in a different working directory,
1114 then restore the previous working directory.
1116 A ``@command{sed}-like'' function.
1119 @subsubsection Module prefix
1121 The license in our last example needs a prefix: this is because of how the
1122 @code{license} module was imported in the package, as @code{#:use-module ((guix licenses)
1123 #:prefix license:)}. The Guile module import mechanism
1124 (@pxref{Using Guile Modules,,, guile, Guile reference manual})
1125 gives the user full control over namespacing: this is needed to avoid
1126 clashes between, say, the
1127 @samp{zlib} variable from @samp{licenses.scm} (a @emph{license} value) and the @samp{zlib} variable
1128 from @samp{compression.scm} (a @emph{package} value).
1130 @node Other build systems
1131 @subsection Other build systems
1133 What we've seen so far covers the majority of packages using a build system
1134 other than the @code{trivial-build-system}. The latter does not automate anything
1135 and leaves you to build everything manually. This can be more demanding and we
1136 won't cover it here for now, but thankfully it is rarely necessary to fall back
1139 For the other build systems, such as ASDF, Emacs, Perl, Ruby and many more, the
1140 process is very similar to the GNU build system except for a few specialized
1143 @xref{Build Systems,,, guix, GNU Guix Reference Manual}, for more
1144 information on build systems, or check the source code in the
1145 @samp{$GUIX_CHECKOUT/guix/build} and
1146 @samp{$GUIX_CHECKOUT/guix/build-system} directories.
1148 @node Programmable and automated package definition
1149 @subsection Programmable and automated package definition
1151 We can't repeat it enough: having a full-fledged programming language at hand
1152 empowers us in ways that reach far beyond traditional package management.
1154 Let's illustrate this with some awesome features of Guix!
1156 @node Recursive importers
1157 @subsubsection Recursive importers
1159 You might find some build systems good enough that there is little to do at all
1160 to write a package, to the point that it becomes repetitive and tedious after a
1161 while. A @emph{raison d'être} of computers is to replace human beings at those
1162 boring tasks. So let's tell Guix to do this for us and create the package
1163 definition of an R package from CRAN (the output is trimmed for conciseness):
1166 $ guix import cran --recursive walrus
1168 (define-public r-mc2d
1172 (define-public r-jmvcore
1176 (define-public r-wrs2
1180 (define-public r-walrus
1187 (uri (cran-uri "walrus" version))
1190 "1nk2glcvy4hyksl5ipq2mz8jy4fss90hx6cq98m3w96kzjni6jjj"))))
1191 (build-system r-build-system)
1193 `(("r-ggplot2" ,r-ggplot2)
1194 ("r-jmvcore" ,r-jmvcore)
1196 ("r-wrs2" ,r-wrs2)))
1197 (home-page "https://github.com/jamovi/walrus")
1198 (synopsis "Robust Statistical Methods")
1200 "This package provides a toolbox of common robust statistical
1201 tests, including robust descriptives, robust t-tests, and robust ANOVA.
1202 It is also available as a module for 'jamovi' (see
1203 <https://www.jamovi.org> for more information). Walrus is based on the
1204 WRS2 package by Patrick Mair, which is in turn based on the scripts and
1205 work of Rand Wilcox. These analyses are described in depth in the book
1206 'Introduction to Robust Estimation & Hypothesis Testing'.")
1210 The recursive importer won't import packages for which Guix already has package
1211 definitions, except for the very first.
1213 Not all applications can be packaged this way, only those relying on a select
1214 number of supported systems. Read about the full list of importers in
1215 the guix import section of the manual
1216 (@pxref{Invoking guix import,,, guix, GNU Guix Reference Manual}).
1218 @node Automatic update
1219 @subsubsection Automatic update
1221 Guix can be smart enough to check for updates on systems it knows. It can
1222 report outdated package definitions with
1225 $ guix refresh hello
1228 In most cases, updating a package to a newer version requires little more than
1229 changing the version number and the checksum. Guix can do that automatically as
1233 $ guix refresh hello --update
1237 @subsubsection Inheritance
1239 If you've started browsing the existing package definitions, you might have
1240 noticed that a significant number of them have a @code{inherit} field:
1243 (define-public adwaita-icon-theme
1244 (package (inherit gnome-icon-theme)
1245 (name "adwaita-icon-theme")
1249 (uri (string-append "mirror://gnome/sources/" name "/"
1250 (version-major+minor version) "/"
1251 name "-" version ".tar.xz"))
1254 "17fpahgh5dyckgz7rwqvzgnhx53cx9kr2xw0szprc6bnqy977fi8"))))
1256 `(("gtk-encode-symbolic-svg" ,gtk+ "bin")))))
1259 All unspecified fields are inherited from the parent package. This is very
1260 convenient to create alternative packages, for instance with different source,
1261 version or compilation options.
1264 @subsection Getting help
1266 Sadly, some applications can be tough to package. Sometimes they need a patch to
1267 work with the non-standard filesystem hierarchy enforced by the store.
1268 Sometimes the tests won't run properly. (They can be skipped but this is not
1269 recommended.) Other times the resulting package won't be reproducible.
1271 Should you be stuck, unable to figure out how to fix any sort of packaging
1272 issue, don't hesitate to ask the community for help.
1274 See the @uref{https://www.gnu.org/software/guix/contact/, Guix homepage} for information on the mailing lists, IRC, etc.
1277 @subsection Conclusion
1279 This tutorial was a showcase of the sophisticated package management that Guix
1280 boasts. At this point we have mostly restricted this introduction to the
1281 @code{gnu-build-system} which is a core abstraction layer on which more advanced
1282 abstractions are based.
1284 Where do we go from here? Next we ought to dissect the innards of the build
1285 system by removing all abstractions, using the @code{trivial-build-system}: this
1286 should give us a thorough understanding of the process before investigating some
1287 more advanced packaging techniques and edge cases.
1289 Other features worth exploring are the interactive editing and debugging
1290 capabilities of Guix provided by the Guile REPL@.
1292 Those fancy features are completely optional and can wait; now is a good time
1293 to take a well-deserved break. With what we've introduced here you should be
1294 well armed to package lots of programs. You can get started right away and
1295 hopefully we will see your contributions soon!
1298 @subsection References
1302 The @uref{https://www.gnu.org/software/guix/manual/en/html_node/Defining-Packages.html, package reference in the manual}
1305 @uref{https://gitlab.com/pjotrp/guix-notes/blob/master/HACKING.org, Pjotr’s hacking guide to GNU Guix}
1308 @uref{https://www.gnu.org/software/guix/guix-ghm-andreas-20130823.pdf, ``GNU Guix: Package without a scheme!''}, by Andreas Enge
1311 @c *********************************************************************
1312 @node System Configuration
1313 @chapter System Configuration
1315 Guix offers a flexible language for declaratively configuring your Guix
1316 System. This flexibility can at times be overwhelming. The purpose of this
1317 chapter is to demonstrate some advanced configuration concepts.
1319 @pxref{System Configuration,,, guix, GNU Guix Reference Manual} for a complete
1323 * Customizing the Kernel:: Creating and using a custom Linux kernel on Guix System.
1324 * Customizing a Window Manager:: Handle customization of a Window manager on Guix System.
1327 @node Customizing the Kernel
1328 @section Customizing the Kernel
1330 Guix is, at its core, a source based distribution with substitutes
1331 (@pxref{Substitutes,,, guix, GNU Guix Reference Manual}), and as such building
1332 packages from their source code is an expected part of regular package
1333 installations and upgrades. Given this starting point, it makes sense that
1334 efforts are made to reduce the amount of time spent compiling packages, and
1335 recent changes and upgrades to the building and distribution of substitutes
1336 continues to be a topic of discussion within Guix.
1338 The kernel, while not requiring an overabundance of RAM to build, does take a
1339 rather long time on an average machine. The official kernel configuration, as
1340 is the case with many GNU/Linux distributions, errs on the side of
1341 inclusiveness, and this is really what causes the build to take such a long
1342 time when the kernel is built from source.
1344 The Linux kernel, however, can also just be described as a regular old
1345 package, and as such can be customized just like any other package. The
1346 procedure is a little bit different, although this is primarily due to the
1347 nature of how the package definition is written.
1349 The @code{linux-libre} kernel package definition is actually a procedure which
1353 (define* (make-linux-libre version hash supported-systems
1355 ;; A function that takes an arch and a variant.
1356 ;; See kernel-config for an example.
1358 (configuration-file #f)
1359 (defconfig "defconfig")
1360 (extra-options %default-extra-linux-options)
1361 (patches (list %boot-logo-patch)))
1365 The current @code{linux-libre} package is for the 5.1.x series, and is
1369 (define-public linux-libre
1370 (make-linux-libre %linux-libre-version
1372 '("x86_64-linux" "i686-linux" "armhf-linux" "aarch64-linux")
1373 #:patches %linux-libre-5.1-patches
1374 #:configuration-file kernel-config))
1377 Any keys which are not assigned values inherit their default value from the
1378 @code{make-linux-libre} definition. When comparing the two snippets above,
1379 you may notice that the code comment in the first doesn't actually refer to
1380 the @code{#:extra-version} keyword; it is actually for
1381 @code{#:configuration-file}. Because of this, it is not actually easy to
1382 include a custom kernel configuration from the definition, but don't worry,
1383 there are other ways to work with what we do have.
1385 There are two ways to create a kernel with a custom kernel configuration. The
1386 first is to provide a standard @file{.config} file during the build process by
1387 including an actual @file{.config} file as a native input to our custom
1388 kernel. The following is a snippet from the custom @code{'configure} phase of
1389 the @code{make-linux-libre} package definition:
1392 (let ((build (assoc-ref %standard-phases 'build))
1393 (config (assoc-ref (or native-inputs inputs) "kconfig")))
1395 ;; Use a custom kernel configuration file or a default
1396 ;; configuration file.
1399 (copy-file config ".config")
1400 (chmod ".config" #o666))
1401 (invoke "make" ,defconfig))
1404 Below is a sample kernel package. The @code{linux-libre} package is nothing
1405 special and can be inherited from and have its fields overridden like any
1409 (define-public linux-libre/E2140
1411 (inherit linux-libre)
1413 `(("kconfig" ,(local-file "E2140.config"))
1414 ,@@(alist-delete "kconfig"
1415 (package-native-inputs linux-libre))))))
1418 In the same directory as the file defining @code{linux-libre-E2140} is a file
1419 named @file{E2140.config}, which is an actual kernel configuration file. The
1420 @code{defconfig} keyword of @code{make-linux-libre} is left blank here, so the
1421 only kernel configuration in the package is the one which was included in the
1422 @code{native-inputs} field.
1424 The second way to create a custom kernel is to pass a new value to the
1425 @code{extra-options} keyword of the @code{make-linux-libre} procedure. The
1426 @code{extra-options} keyword works with another function defined right below
1430 (define %default-extra-linux-options
1431 `(;; https://lists.gnu.org/archive/html/guix-devel/2014-04/msg00039.html
1432 ("CONFIG_DEVPTS_MULTIPLE_INSTANCES" . #t)
1433 ;; Modules required for initrd:
1434 ("CONFIG_NET_9P" . m)
1435 ("CONFIG_NET_9P_VIRTIO" . m)
1436 ("CONFIG_VIRTIO_BLK" . m)
1437 ("CONFIG_VIRTIO_NET" . m)
1438 ("CONFIG_VIRTIO_PCI" . m)
1439 ("CONFIG_VIRTIO_BALLOON" . m)
1440 ("CONFIG_VIRTIO_MMIO" . m)
1441 ("CONFIG_FUSE_FS" . m)
1443 ("CONFIG_9P_FS" . m)))
1445 (define (config->string options)
1446 (string-join (map (match-lambda
1448 (string-append option "=m"))
1450 (string-append option "=y"))
1452 (string-append option "=n")))
1457 And in the custom configure script from the `make-linux-libre` package:
1460 ;; Appending works even when the option wasn't in the
1461 ;; file. The last one prevails if duplicated.
1462 (let ((port (open-file ".config" "a"))
1463 (extra-configuration ,(config->string extra-options)))
1464 (display extra-configuration port)
1467 (invoke "make" "oldconfig"))))
1470 So by not providing a configuration-file the @file{.config} starts blank, and
1471 then we write into it the collection of flags that we want. Here's another
1475 (define %macbook41-full-config
1476 (append %macbook41-config-options
1480 (@@@@ (gnu packages linux) %default-extra-linux-options)))
1482 (define-public linux-libre-macbook41
1483 ;; XXX: Access the internal 'make-linux-libre' procedure, which is
1484 ;; private and unexported, and is liable to change in the future.
1485 ((@@@@ (gnu packages linux) make-linux-libre) (@@@@ (gnu packages linux) %linux-libre-version)
1486 (@@@@ (gnu packages linux) %linux-libre-hash)
1488 #:extra-version "macbook41"
1489 #:patches (@@@@ (gnu packages linux) %linux-libre-5.1-patches)
1490 #:extra-options %macbook41-config-options))
1493 In the above example @code{%filesystems} is a collection of flags enabling
1494 different filesystem support, @code{%efi-support} enables EFI support and
1495 @code{%emulation} enables a x86_64-linux machine to act in 32-bit mode also.
1496 @code{%default-extra-linux-options} are the ones quoted above, which had to be
1497 added in since they were replaced in the @code{extra-options} keyword.
1499 This all sounds like it should be doable, but how does one even know which
1500 modules are required for a particular system? Two places that can be helpful
1501 in trying to answer this question is the
1502 @uref{https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Kernel, Gentoo
1504 @uref{https://www.kernel.org/doc/html/latest/admin-guide/README.html?highlight=localmodconfig,
1505 documentation from the kernel itself}. From the kernel documentation, it
1506 seems that @code{make localmodconfig} is the command we want.
1508 In order to actually run @code{make localmodconfig} we first need to get and
1509 unpack the kernel source code:
1512 tar xf $(guix build linux-libre --source)
1515 Once inside the directory containing the source code run @code{touch .config}
1516 to create an initial, empty @file{.config} to start with. @code{make
1517 localmodconfig} works by seeing what you already have in @file{.config} and
1518 letting you know what you're missing. If the file is blank then you're
1519 missing everything. The next step is to run:
1522 guix environment linux-libre -- make localmodconfig
1525 and note the output. Do note that the @file{.config} file is still empty.
1526 The output generally contains two types of warnings. The first start with
1527 "WARNING" and can actually be ignored in our case. The second read:
1530 module pcspkr did not have configs CONFIG_INPUT_PCSPKR
1533 For each of these lines, copy the @code{CONFIG_XXXX_XXXX} portion into the
1534 @file{.config} in the directory, and append @code{=m}, so in the end it looks
1538 CONFIG_INPUT_PCSPKR=m
1542 After copying all the configuration options, run @code{make localmodconfig}
1543 again to make sure that you don't have any output starting with ``module''.
1544 After all of these machine specific modules there are a couple more left that
1545 are also needed. @code{CONFIG_MODULES} is necessary so that you can build and
1546 load modules separately and not have everything built into the kernel.
1547 @code{CONFIG_BLK_DEV_SD} is required for reading from hard drives. It is
1548 possible that there are other modules which you will need.
1550 This post does not aim to be a guide to configuring your own kernel however,
1551 so if you do decide to build a custom kernel you'll have to seek out other
1552 guides to create a kernel which is just right for your needs.
1554 The second way to setup the kernel configuration makes more use of Guix's
1555 features and allows you to share configuration segments between different
1556 kernels. For example, all machines using EFI to boot have a number of EFI
1557 configuration flags that they need. It is likely that all the kernels will
1558 share a list of filesystems to support. By using variables it is easier to
1559 see at a glance what features are enabled and to make sure you don't have
1560 features in one kernel but missing in another.
1562 Left undiscussed however, is Guix's initrd and its customization. It is
1563 likely that you'll need to modify the initrd on a machine using a custom
1564 kernel, since certain modules which are expected to be built may not be
1565 available for inclusion into the initrd.
1567 @node Customizing a Window Manager
1568 @section Customizing a Window Manager
1575 You could install StumpWM with a Guix system by adding
1576 @code{stumpwm-checkout} and optionally @code{`(,stumpwm-checkout "lib")}
1577 packages to a system configuration file, e.g. @file{/etc/config.scm}.
1579 An example configuration can look like this:
1583 (use-package-modules wm)
1587 (packages (append (list sbcl stumpwm-checkout `(,stumpwm-checkout "lib"))
1591 @cindex stumpwm fonts
1592 By default StumpWM uses X11 fonts, which could be small or pixelated on
1593 your system. You could fix this by installing StumpWM contrib Lisp
1594 module @code{sbcl-stumpwm-ttf-fonts}, adding it to Guix system packages:
1598 (use-package-modules fonts wm)
1602 (packages (append (list sbcl stumpwm-checkout `(,stumpwm-checkout "lib"))
1603 sbcl-stumpwm-ttf-fonts font-dejavu %base-packages)))
1606 Then you need to add the following code to a StumpWM configuration file
1607 @file{~/.stumpwm.d/init.lisp}:
1610 (require :ttf-fonts)
1611 (setf xft:*font-dirs* '("/run/current-system/profile/share/fonts/"))
1612 (setf clx-truetype:+font-cache-filename+ (concat (getenv "HOME") "/.fonts/font-cache.sexp"))
1614 (set-font (make-instance 'xft:font :family "DejaVu Sans Mono" :subfamily "Book" :size 11))
1617 @c *********************************************************************
1618 @node Advanced package management
1619 @chapter Advanced package management
1621 Guix is a functional package manager that offers many features beyond
1622 what more traditional package managers can do. To the uninitiated,
1623 those features might not have obvious use cases at first. The purpose
1624 of this chapter is to demonstrate some advanced package management
1627 @pxref{Package Management,,, guix, GNU Guix Reference Manual} for a complete
1631 * Guix Profiles in Practice:: Strategies for multiple profiles and manifests.
1634 @node Guix Profiles in Practice
1635 @section Guix Profiles in Practice
1637 Guix provides a very useful feature that may be quite foreign to newcomers:
1638 @emph{profiles}. They are a way to group package installations together and all users
1639 on the same system are free to use as many profiles as they want.
1641 Whether you're a developer or not, you may find that multiple profiles bring you
1642 great power and flexibility. While they shift the paradigm somewhat compared to
1643 @emph{traditional package managers}, they are very convenient to use once you've
1644 understood how to set them up.
1646 If you are familiar with Python's @samp{virtualenv}, you can think of a profile as a
1647 kind of universal @samp{virtualenv} that can hold any kind of software whatsoever, not
1648 just Python software. Furthermore, profiles are self-sufficient: they capture
1649 all the runtime dependencies which guarantees that all programs within a profile
1650 will always work at any point in time.
1652 Multiple profiles have many benefits:
1656 Clean semantic separation of the various packages a user needs for different contexts.
1659 Multiple profiles can be made available into the environment either on login
1660 or within a dedicated shell.
1663 Profiles can be loaded on demand. For instance, the user can use multiple
1664 shells, each of them running different profiles.
1667 Isolation: Programs from one profile will not use programs from the other, and
1668 the user can even install different versions of the same programs to the two
1669 profiles without conflict.
1672 Deduplication: Profiles share dependencies that happens to be the exact same.
1673 This makes multiple profiles storage-efficient.
1676 Reproducible: when used with declarative manifests, a profile can be fully
1677 specified by the Guix commit that was active when it was set up. This means
1678 that the exact same profile can be
1679 @uref{https://guix.gnu.org/blog/2018/multi-dimensional-transactions-and-rollbacks-oh-my/,
1680 set up anywhere and anytime}, with just the commit information. See the
1681 section on @ref{Reproducible profiles}.
1684 Easier upgrades and maintenance: Multiple profiles make it easy to keep
1685 package listings at hand and make upgrades completely friction-less.
1688 Concretely, here follows some typical profiles:
1692 The dependencies of a project you are working on.
1695 Your favourite programming language libraries.
1698 Laptop-specific programs (like @samp{powertop}) that you don't need on a desktop.
1701 @TeX{}live (this one can be really useful when you need to install just one
1702 package for this one document you've just received over email).
1708 Let's dive in the set up!
1710 @node Basic setup with manifests
1711 @subsection Basic setup with manifests
1713 A Guix profile can be set up @emph{via} a so-called @emph{manifest specification} that looks like
1717 (specifications->manifest
1719 ;; Version 1.3 of package-2.
1721 ;; The "lib" output of package-3.
1727 @pxref{Invoking guix package,,, guix, GNU Guix Reference Manual}, for
1730 We can create a manifest specification per profile and install them this way:
1733 GUIX_EXTRA_PROFILES=$HOME/.guix-extra-profiles
1734 mkdir -p "$GUIX_EXTRA_PROFILES"/my-project # if it does not exist yet
1735 guix package --manifest=/path/to/guix-my-project-manifest.scm --profile="$GUIX_EXTRA_PROFILES"/my-project/my-project
1738 Here we set an arbitrary variable @samp{GUIX_EXTRA_PROFILES} to point to the directory
1739 where we will store our profiles in the rest of this article.
1741 Placing all your profiles in a single directory, with each profile getting its
1742 own sub-directory, is somewhat cleaner. This way, each sub-directory will
1743 contain all the symlinks for precisely one profile. Besides, "looping over
1744 profiles" becomes obvious from any programming language (e.g. a shell script) by
1745 simply looping over the sub-directories of @samp{$GUIX_EXTRA_PROFILES}.
1747 Note that it's also possible to loop over the output of
1750 guix package --list-profiles
1753 although you'll probably have to filter out @samp{~/.config/guix/current}.
1755 To enable all profiles on login, add this to your @samp{~/.bash_profile} (or similar):
1758 for i in $GUIX_EXTRA_PROFILES/*; do
1759 profile=$i/$(basename "$i")
1760 if [ -f "$profile"/etc/profile ]; then
1761 GUIX_PROFILE="$profile"
1762 . "$GUIX_PROFILE"/etc/profile
1768 Note to Guix System users: the above reflects how your default profile
1769 @samp{~/.guix-profile} is activated from @samp{/etc/profile}, that latter being loaded by
1770 @samp{~/.bashrc} by default.
1772 You can obviously choose to only enable a subset of them:
1775 for i in "$GUIX_EXTRA_PROFILES"/my-project-1 "$GUIX_EXTRA_PROFILES"/my-project-2; do
1776 profile=$i/$(basename "$i")
1777 if [ -f "$profile"/etc/profile ]; then
1778 GUIX_PROFILE="$profile"
1779 . "$GUIX_PROFILE"/etc/profile
1785 When a profile is off, it's straightforward to enable it for an individual shell
1786 without "polluting" the rest of the user session:
1789 GUIX_PROFILE="path/to/my-project" ; . "$GUIX_PROFILE"/etc/profile
1792 The key to enabling a profile is to @emph{source} its @samp{etc/profile} file. This file
1793 contains shell code that exports the right environment variables necessary to
1794 activate the software contained in the profile. It is built automatically by
1795 Guix and meant to be sourced.
1796 It contains the same variables you would get if you ran:
1799 guix package --search-paths=prefix --profile=$my_profile"
1802 Once again, see (@pxref{Invoking guix package,,, guix, GNU Guix Reference Manual})
1803 for the command line options.
1805 To upgrade a profile, simply install the manifest again:
1808 guix package -m /path/to/guix-my-project-manifest.scm -p "$GUIX_EXTRA_PROFILES"/my-project/my-project
1811 To upgrade all profiles, it's easy enough to loop over them. For instance,
1812 assuming your manifest specifications are stored in
1813 @samp{~/.guix-manifests/guix-$profile-manifest.scm}, with @samp{$profile} being the name
1814 of the profile (e.g. "project1"), you could do the following in Bourne shell:
1817 for profile in "$GUIX_EXTRA_PROFILES"/*; do
1818 guix package --profile="$profile" --manifest="$HOME/.guix-manifests/guix-$profile-manifest.scm"
1822 Each profile has its own generations:
1825 guix package -p "$GUIX_EXTRA_PROFILES"/my-project/my-project --list-generations
1828 You can roll-back to any generation of a given profile:
1831 guix package -p "$GUIX_EXTRA_PROFILES"/my-project/my-project --switch-generations=17
1834 Finally, if you want to switch to a profile without inheriting from the
1835 current environment, you can activate it from an empty shell:
1838 env -i $(which bash) --login --noprofile --norc
1839 . my-project/etc/profile
1842 @node Required packages
1843 @subsection Required packages
1845 Activating a profile essentially boils down to exporting a bunch of
1846 environmental variables. This is the role of the @samp{etc/profile} within the
1849 @emph{Note: Only the environmental variables of the packages that consume them will
1852 For instance, @samp{MANPATH} won't be set if there is no consumer application for man
1853 pages within the profile. So if you need to transparently access man pages once
1854 the profile is loaded, you've got two options:
1858 Either export the variable manually, e.g.
1860 export MANPATH=/path/to/profile$@{MANPATH:+:@}$MANPATH
1864 Or include @samp{man-db} to the profile manifest.
1867 The same is true for @samp{INFOPATH} (you can install @samp{info-reader}),
1868 @samp{PKG_CONFIG_PATH} (install @samp{pkg-config}), etc.
1870 @node Default profile
1871 @subsection Default profile
1873 What about the default profile that Guix keeps in @samp{~/.guix-profile}?
1875 You can assign it the role you want. Typically you would install the manifest
1876 of the packages you want to use all the time.
1878 Alternatively, you could keep it "manifest-less" for throw-away packages
1879 that you would just use for a couple of days.
1880 This way makes it convenient to run
1883 guix install package-foo
1884 guix upgrade package-bar
1887 without having to specify the path to a profile.
1889 @node The benefits of manifests
1890 @subsection The benefits of manifests
1892 Manifests are a convenient way to keep your package lists around and, say,
1893 to synchronize them across multiple machines using a version control system.
1895 A common complaint about manifests is that they can be slow to install when they
1896 contain large number of packages. This is especially cumbersome when you just
1897 want get an upgrade for one package within a big manifest.
1899 This is one more reason to use multiple profiles, which happen to be just
1900 perfect to break down manifests into multiple sets of semantically connected
1901 packages. Using multiple, small profiles provides more flexibility and
1904 Manifests come with multiple benefits. In particular, they ease maintenance:
1908 When a profile is set up from a manifest, the manifest itself is
1909 self-sufficient to keep a "package listing" around and reinstall the profile
1910 later or on a different system. For ad-hoc profiles, we would need to
1911 generate a manifest specification manually and maintain the package versions
1912 for the packages that don't use the default version.
1915 @code{guix package --upgrade} always tries to update the packages that have
1916 propagated inputs, even if there is nothing to do. Guix manifests remove this
1920 When partially upgrading a profile, conflicts may arise (due to diverging
1921 dependencies between the updated and the non-updated packages) and they can be
1922 annoying to resolve manually. Manifests remove this problem altogether since
1923 all packages are always upgraded at once.
1926 As mentioned above, manifests allow for reproducible profiles, while the
1927 imperative @code{guix install}, @code{guix upgrade}, etc. do not, since they produce
1928 different profiles every time even when they hold the same packages. See
1929 @uref{https://issues.guix.gnu.org/issue/33285, the related discussion on the matter}.
1932 Manifest specifications are usable by other @samp{guix} commands. For example, you
1933 can run @code{guix weather -m manifest.scm} to see how many substitutes are
1934 available, which can help you decide whether you want to try upgrading today
1935 or wait a while. Another example: you can run @code{guix pack -m manifest.scm} to
1936 create a pack containing all the packages in the manifest (and their
1937 transitive references).
1940 Finally, manifests have a Scheme representation, the @samp{<manifest>} record type.
1941 They can be manipulated in Scheme and passed to the various Guix @uref{https://en.wikipedia.org/wiki/Api, APIs}.
1944 It's important to understand that while manifests can be used to declare
1945 profiles, they are not strictly equivalent: profiles have the side effect that
1946 they "pin" packages in the store, which prevents them from being
1947 garbage-collected (@pxref{Invoking guix gc,,, guix, GNU Guix Reference Manual})
1948 and ensures that they will still be available at any point in
1951 Let's take an example:
1955 We have an environment for hacking on a project for which there isn't a Guix
1956 package yet. We build the environment using a manifest, and then run @code{guix
1957 environment -m manifest.scm}. So far so good.
1960 Many weeks pass and we have run a couple of @code{guix pull} in the mean time.
1961 Maybe a dependency from our manifest has been updated; or we may have run
1962 @code{guix gc} and some packages needed by our manifest have been
1966 Eventually, we set to work on that project again, so we run @code{guix environment
1967 -m manifest.scm}. But now we have to wait for Guix to build and install
1971 Ideally, we could spare the rebuild time. And indeed we can, all we need is to
1972 install the manifest to a profile and use @code{GUIX_PROFILE=/the/profile;
1973 . "$GUIX_PROFILE"/etc/profile} as explained above: this guarantees that our
1974 hacking environment will be available at all times.
1976 @emph{Security warning:} While keeping old profiles around can be convenient, keep in
1977 mind that outdated packages may not have received the latest security fixes.
1979 @node Reproducible profiles
1980 @subsection Reproducible profiles
1982 To reproduce a profile bit-for-bit, we need two pieces of information:
1988 a Guix channel specification.
1991 Indeed, manifests alone might not be enough: different Guix versions (or
1992 different channels) can produce different outputs for a given manifest.
1994 You can output the Guix channel specification with @samp{guix describe
1996 Save this to a file, say @samp{channel-specs.scm}.
1998 On another computer, you can use the channel specification file and the manifest
1999 to reproduce the exact same profile:
2002 GUIX_EXTRA_PROFILES=$HOME/.guix-extra-profiles
2003 GUIX_EXTRA=$HOME/.guix-extra
2005 mkdir "$GUIX_EXTRA"/my-project
2006 guix pull --channels=channel-specs.scm --profile "$GUIX_EXTRA/my-project/guix"
2008 mkdir -p "$GUIX_EXTRA_PROFILES/my-project"
2009 "$GUIX_EXTRA"/my-project/guix/bin/guix package --manifest=/path/to/guix-my-project-manifest.scm --profile="$GUIX_EXTRA_PROFILES"/my-project/my-project
2012 It's safe to delete the Guix channel profile you've just installed with the
2013 channel specification, the project profile does not depend on it.
2015 @c *********************************************************************
2016 @node Acknowledgments
2017 @chapter Acknowledgments
2019 Guix is based on the @uref{https://nixos.org/nix/, Nix package manager},
2020 which was designed and
2021 implemented by Eelco Dolstra, with contributions from other people (see
2022 the @file{nix/AUTHORS} file in Guix.) Nix pioneered functional package
2023 management, and promoted unprecedented features, such as transactional
2024 package upgrades and rollbacks, per-user profiles, and referentially
2025 transparent build processes. Without this work, Guix would not exist.
2027 The Nix-based software distributions, Nixpkgs and NixOS, have also been
2028 an inspiration for Guix.
2030 GNU@tie{}Guix itself is a collective work with contributions from a
2031 number of people. See the @file{AUTHORS} file in Guix for more
2032 information on these fine people. The @file{THANKS} file lists people
2033 who have helped by reporting bugs, taking care of the infrastructure,
2034 providing artwork and themes, making suggestions, and more---thank you!
2036 This document includes adapted sections from articles that have previously
2037 been published on the Guix blog at @uref{https://guix.gnu.org/blog}.
2040 @c *********************************************************************
2041 @node GNU Free Documentation License
2042 @appendix GNU Free Documentation License
2043 @cindex license, GNU Free Documentation License
2044 @include fdl-1.3.texi
2046 @c *********************************************************************
2048 @unnumbered Concept Index
2054 @c ispell-local-dictionary: "american";