[sterlind]

How does writing Guix Lisp expressions compare to writing Nix? Is it pretty succinct and intuitive? Do patterns make a little bit better sense?

It took me a long time to get the hang of the Nix design patterns like the three different kinds of overrides and the module system. Curious if it plays better in Lisp.

[rekado]

"succinct" is hard to answer. It depends a lot on the upstream package. For most packages the package expression looks like data:

    (define-public r-valr
      (package
        (name "r-valr")
        (version "0.5.0")
        (source
         (origin
           (method url-fetch)
           (uri (cran-uri "valr" version))
           (sha256
            (base32
             "14jhrwkiwmha3vlmm7b50n2xxyizj6ddmy89gb20mpzq7qhz1ika"))))
        (build-system r-build-system)
        (propagated-inputs
         `(("r-broom" ,r-broom)
           ("r-dplyr" ,r-dplyr)
           ("r-ggplot2" ,r-ggplot2)
           ("r-rcpp" ,r-rcpp)
           ("r-readr" ,r-readr)
           ("r-rlang" ,r-rlang)
           ("r-stringr" ,r-stringr)
           ("r-tibble" ,r-tibble)))
        (home-page "https://github.com/rnabioco/valr")
        (synopsis "Genome interval arithmetic in R")
        (description
         "This package enables you to read and manipulate genome intervals and
    signals.  It provides functionality similar to command-line tool suites within
    R, enabling interactive analysis and visualization of genome-scale data.")
        (license license:expat)))

This defines the name "r-valr" to be a "package" value with the given fields. The "source" field describes how Guix should obtain the source tarball ("url-fetch" is a procedure that implements a URL downloader, but there are others like "git-fetch", "hg-fetch", etc) and what the hash of that data is supposed to be. The "build-system" field tells Guix how to build the thing. "r-build-system" is a very succinct way to say "do with this package as you do for all other R packages: unpack the tarball, run `R CMD bla`, then run the tests, etc". We've got quite a few such build systems: "gnu-build-system", "cmake-build-system", "python-build-system", "ant-build-system", ... All of these can be further configured via the "arguments" package field, which isn't used here, because this is a boring package.

The "propagated-inputs" field is an association list of arbitrary labels to actual package values --- the things on the right hand side are variable names that are bound to package values, which are unquoted here, so this field really contains actual references to these other package values. The result is a lazily constructed graph of package values.

Some packages can be really nasty, though, when the developers decided to ignore conventions and implement their very own way to build their very special software. We can usually accommodate those packages by starting out with e.g. the gnu-build-system and then modifying the build phases: deleting the "configure" phase, adding a custom phase before the "build", replacing the "install" phase, etc. The system is flexible enough for all of this, but for really ... special software I would no longer call this "succinct" or "intuitive".

That said, most packages are easy. Almost all R packages, for example, look like the one above. But there are some really frustrating ones like Tensorflow (due to the fact that we use CMake instead of Bazel because Bazel hasn't been bootstrapped yet) or the old JDKs (that we use as part of a longer bootstrap chain) that are plain ugly. You just need to know when to give up, I suppose :)

[sterlind]

> You just need to know when to give up, I suppose :)

Oh gosh I relate to this. I tried to package 3DSlicer for NixOS, which uses a cmake superbuild of dozens of dependent projects, which it fetched during compile and required a very special GCC. I had to give up; it was making me too depressed.

Thank you for sharing how Guix derivations work. It seems very similar semantically to Nix, but I like the build-system method. In nix we have e.g. buildDotnetPackage, buildBazelPackage functions which are overridden, but there's not a clean interface for build systems. I like it.

Is the module system similar to Nix's? Nix modules define imports, config schema and config values, which are merged together to produce an expression for the state of the whole system, e.g. configuration.nix. How's that work in GuixSD?

[rekado]

> Is the module system similar to Nix's? Nix modules define imports, config schema and config values, which are merged together to produce an expression for the state of the whole system, e.g. configuration.nix. How's that work in GuixSD?

The way the Guix system is configured differs a lot from how it's done in NixOS. (Note, though, that I've never used NixOS, so I'll just talk about how it works in Guix.)

First about the term "modules" to avoid confusion: Guix code is organized in Guile modules. A Guile module is a file containing definitions. A module can export variable names. Other modules can use those variable names. That's just like how you'd do "import foo" in Python --- in Guile you do "(use-modules (where foo is))".

This is nothing to do with system configuration, of course; it's just a language feature.

The way a system is configured is through the `operating-system` record. Much like the `package` record for defining first class package values the `operating-system` record is used to declare operating systems. Here's an example straight from the manual:

    (use-modules (gnu))
    (use-service-modules networking ssh)
    (use-package-modules screen)

    (operating-system
      (host-name "komputilo")
      (timezone "Europe/Berlin")
      (locale "en_US.utf8")

      ;; Boot in "legacy" BIOS mode, assuming /dev/sdX is the
      ;; target hard disk, and "my-root" is the label of the target
      ;; root file system.
      (bootloader (bootloader-configuration
                    (bootloader grub-bootloader)
                    (target "/dev/sdX")))
      (file-systems (cons (file-system
                            (device (file-system-label "my-root"))
                            (mount-point "/")
                            (type "ext4"))
                          %base-file-systems))

      ;; This is where user accounts are specified.  The "root"
      ;; account is implicit, and is initially created with the
      ;; empty password.
      (users (cons (user-account
                    (name "alice")
                    (comment "Bob's sister")
                    (group "users")

                    ;; Adding the account to the "wheel" group
                    ;; makes it a sudoer.  Adding it to "audio"
                    ;; and "video" allows the user to play sound
                    ;; and access the webcam.
                    (supplementary-groups '("wheel"
                                            "audio" "video")))
                   %base-user-accounts))

      ;; Globally-installed packages.
      (packages (cons screen %base-packages))

      ;; Add services to the baseline: a DHCP client and
      ;; an SSH server.
      (services (append (list (service dhcp-client-service-type)
                              (service openssh-service-type
                                       (openssh-configuration
                                        (port-number 2222))))
                        %base-services)))

The "packages" field is for declaring globally available packages, nothing special. What's interesting, though, is the "services" field. This is not just about services in the sense of daemons (i.e. Shepherd services that can be started and stopped), but about anything really to extend the system.

System services can be composed and may extend one another, see <https://www.gnu.org/software/guix/manual/en/html_node/Servic.... This can be used for complex system setup like web applications that require a web server configuration (e.g. by adding an nginx server block), a database, and so on. An example is the Zabbix system service. We also use the service framework for generating PAM policies, creating files in /etc, for udev rules, etc.

This framework was described also in comparison with NixOS in a 2015 blog post: https://www.gnu.org/software/guix/blog/2015/service-composit...

"guix system" operates on an "operating-system" value (read from a file or read as a Scheme expression) to instantiate a VM, a container image, or a bare-metal system.

[equalunique]

Thank you for the helpful explanation of guix packaging.