Guix Clojure Config

Functional operating systems like NixOS and Guix allow you to have reproducible builds starting at the very bottom of the stack. The entire environment including the packages, services, and configuration are able to be described declaratively. This is ideal for a development machine because you are able to put the entire environment into version control. If a computer breaks and you want to be up and running quickly, you can automate the entire process of recreating your previous environment in a reproducible way. You can also keep multiple machines in sync so that your ever evolving workflow is not interrupted.

You can use these same configuration tools from your development machine in production, however things like Kubernetes and Docker are still much more complete than functional operating systems. The documentation for functional operating systems are currently sparse. There also aren't nearly as many prebuilt configurations and services for these systems.

Many languages have a virtual environment system designed for producing reproducible builds and mixing and matching package versions. With a functional operating system you can create virtual environments between many different programming languages and tools even if your language of choice doesn't have those declarative tools available.

Guix is preferred because it's configuration language is a full programming language, rather than an ad hoc language. Guix uses Guile Scheme as it's configuration language which is friendly to Clojure developers who are used to a lispy language. It is the official configuration of GNU projects so there will be many other configurations available to interoperate with. Using the same configuration language across different environments will have similar benefits as Lisp machines and the Emacs environment such as having a consistent interface and being able to radically customize every aspect of the system.

When Installing Guix you may find the official documentation terse and incomplete. I highly recommend the System Crafters series on using guix. It has excellent tutorials as well as instructions for using the Nonguix package channel which is unable to be explained in the official documentation for Philosophical Reasons.

Guix has several different mechanisms for specifying packages to install. Guix manifests are the simplest.

Early in my journey using guix there was an error for the package definition for Clojure and I needed the latest version. There was a delay. There is always the worry with package managers that you will be too far behind the main release schedule. For the most part guix stays fairly close to the bleeding edge once a package is in the repository.

You're still going to need to use other build tools to get real work done. Do the benefits of a consistent configuration interface dissapear when there are exceptions?

People sometimes use guix to manage their emacs packages rather than one of the emacs package managers. Whether this is a good idea is still up for debate. Much less whether this would be good to do with other programming languages besides elisp. The strongest argument I've seen against using guix as your emacs package manager is an argument in favor of the borg package manager for emacs which does a better job of integrating access to source code than guix currently does. Currently I still use straight.el because it is integrated with doom emacs and I haven't started building my own configuration for emacs.

If you have a favorite language why not use that for configuration rather than also learning Guile? Does the benefit of a shared language outweigh the cost of adding a language to your working set of languages?

Sean Corfield (the primary author of many deps related templating tools like clj-new) has sophisticated thoughts on architecting build systems. I definitely want to keep an eye on what's going on his blog.

• Author: Brian Marco
• Created: 2023-02-08
• Last Updated: 2023-02-12