diff options
| -rw-r--r-- | posts/2022-09-23-guix-for-dev.md | 190 |
1 files changed, 190 insertions, 0 deletions
diff --git a/posts/2022-09-23-guix-for-dev.md b/posts/2022-09-23-guix-for-dev.md new file mode 100644 index 0000000..3f92c62 --- /dev/null +++ b/posts/2022-09-23-guix-for-dev.md @@ -0,0 +1,190 @@ +title: Guix for development +date: 2022-09-23 15:00:00 +tags: guix +summary: Using Guix in a software development workflow +--- + +[This wonderful +article](https://gexp.no/blog/hacking-anything-with-gnu-guix.html) by +Marius Bakke (thanks for using +[Haunt](https://dthompson.us/projects/haunt.html) btw!) about `guix +shell` hit the orange website front page recently. I left a comment +to the effect of “hell yeah I use it for all my projects!” and someone +asked me for an example of what I do. I sent them some links but I +thought hey, this could be a blog post and I haven't written one of +those in *years*! + +The tl;dr is that [Guix](https://guix.gnu.org) is a fantastic +developer productivity tool that can easily automate development +environment creation and pre-release build testing and you should give +it a try but if you like what you already use then that's fine, too. + +## There's gotta be a better way! + +This is the “Are you tired of *this*?” part of the infomercial. Read +the next few paragraphs and picture me, in grayscale color, struggling +to hold a large stack of boxes, all labeled “software.” I continue +struggling to balance the boxes as you read. When you've reached the +last paragraph of the section, I fall over, the boxes land on top of +me and all over the floor, I'm covered in spaghetti, and in an +exasperated voice I shout "There's gotta be a better way!" + +When setting up a new computer for software development, I want to go +from `git clone` to `make` in as little time as possible (adjust that +for your VCS and build system of choice.) In the old days, this meant +manually installing the dependencies through the distro package +manager. If things are organized, the project README will have a list +of what is needed and it's not so bad. If things are less organized, +it's a cycle of installing packages and running `./configure` or +whatever until it succeeds. Hopefully none of the dependencies are +too new to be found in the distro. And when working on multiple +projects, hopefully there's no conflicts between the dependencies +required for each of them, because your development environment is the +entire system and there's no way to isolate different projects from +each other. + +Of course, different programming languages provide their own sets of +tools for managing multiple projects. Python has virtualenv, Ruby has +rvm and bundler, Node has nvm and npm, etc. But their domain is +restricted to only the dependencies for that language and their +runtimes. A system package manager is needed to bootstrap their use. + +Nowadays it's “just use Docker.” Docker's take is that all this +package management stuff is just too complicated. Instead, just +create a disk image per project that encapsulates this hodgepodge of +package managers and bespoke, artisinal, small-batch builds that gets +run in isolation via Linux namespace magic. It works, of course, but +I think Dockerfiles are clunky and the rather extreme level of +isolation is usually unnecessary and makes things overly complicated +for projects that need to interact with, say, the windowing system of +the host computer. A lot of people are happy with Docker, though. +Maybe you are, too. That's fine! + +What I really want to say is “Computer, provision a development +environment containing Guile 3, SDL2, make, and texinfo!” and have +Majel Barrett-Roddenberry tell me that all of those things have been +made available to me on my host system. No container, no virtual +machine. It shouldn't matter if I have Guile 2 installed system-wide, +Guile 3 should still be what's used in the context of the project. +This is how Guix works and it's very good and cool and I'm going to +tell you all about how I use it. + +## Two easy payments and one complicated payment + +Guix is a general-purpose package manager that can be used on top of +any distro and also *it is a distro*. I use it both on Ubuntu and as +a standalone distro. It takes a few minutes to [install on top of an +existing +distro](https://guix.gnu.org/manual/en/html_node/Binary-Installation.html) +but once it's there the magic begins. Software installed with Guix is +not installed globally (`/usr`), which allows it to act like a +`virtualenv` for everything. Guix provides the [guix +shell](https://guix.gnu.org/en/manual/devel/en/html_node/Invoking-guix-shell.html) +tool for creating temporary environments with an arbitrary set of +software inside. + +Let's start with a real world example. Here's how to build Guile's +SDL2 bindings from a Git checkout using Guix: + +``` +git clone https://git.dthompson.us/guile-sdl2.git +cd guile-sdl2 +echo $PWD >> $HOME/.config/guix/shell-authorized-directories +guix shell +./configure +make +``` + +Looks pretty straightforward except for that third line, which +whitelists the project directory as a place that `guix shell` can be +used for security reasons (though I think the potential risk is not +worth this extra step that I'm now burdened with explaining!) I don't +have to look at a `README` to know what software I need to install. +The project is pre-configured to work with Guix and the software it +installs does not affect the whole system. + +So what's happening? Well, `guix shell` automatically searches the +current directory for a `guix.scm` file and loads it. Inside that +file is all the information needed to construct an environment that +can build the source code: + +```scheme +(use-modules (guix git) + (guix packages) + (guix licenses) + (guix build-system gnu) + (gnu packages) + (gnu packages autotools) + (gnu packages guile) + (gnu packages pkg-config) + (gnu packages sdl) + (gnu packages texinfo)) + +(package + (name "guile-sdl2") + (version "0.7.0") + (source (git-checkout (url (dirname (current-filename))))) + (build-system gnu-build-system) + (arguments + '(#:make-flags '("GUILE_AUTO_COMPILE=0") + #:phases + (modify-phases %standard-phases + (add-after 'unpack 'bootstrap + (lambda _ (invoke "sh" "bootstrap")))))) + (native-inputs (list autoconf automake pkg-config texinfo)) + (inputs (list guile-3.0-latest sdl2 sdl2-image sdl2-mixer sdl2-ttf)) + (synopsis "Guile bindings for SDL2") + (description "Guile-SDL2 provides pure Guile Scheme bindings to the SDL2 C shared +library via the foreign function interface.") + (home-page "https://git.dthompson.us/guile-sdl2.git") + (license lgpl3+)) +``` + +This is what's known as “configuration as code” and it looks kinda +like a `package.json` (not code) or a `.gemspec` (code) file. +`guix.scm` contains not just inert data, but a small Scheme program +that returns a Guix package. `guix shell` sees to it that all of the +dependencies (listed in the `inputs` and `native-inputs` sections) are +available within the shell session it creates by downloading (or +building, if necessary) the entire dependency tree. Going back to the +earlier example, `./configure` and `make` run in the context of that +new shell session and are thus able to complete successfully. + +Should you want/need more isolation from the host system, `guix shell` +has you covered. The `--pure` flag will clear out most existing +environments variables, such as `$PATH`, so that the resulting +environment does not contain pointers to places like `/usr`. For more +Docker-like isolation, the `--container` flag can be used, which will +run the new shell session within a set of Linux namespaces so that the +host system is inaccessible. I rarely use either flag. + +`guix shell` runs pretty fast after it downloads all the required +software the first time, and it can be run non-interactively, so it's +pretty handy to use in scripts. I like to use it with Emacs' +compilation feature. I run `M-x compile` and use `guix shell -D -f +guix.scm -- make` as the compilation command to run `make` in the +proper context. When running `guix shell` non-interactively, it must +be made explicit that `guix.scm` should be loaded (a minor usability +issue, IMO.) + +The same `guix.scm` file can be used with more than just `guix shell`. +For example, `guix build -f guix.scm` will build the project from +scratch outside of your project directory, which could reveal issues +like forgetting to commit a new file (something I've done too many +times.) `guix package -f guix.scm` will build *and* install the +package, which could be used to confirm that a “real” build works the +same as the version in the development environment. + +## Supplies are limited, order today! + +I hope this helps someone out there considering a Guix-based +development workflow or is just wondering what the deal is. I haven't +come across too many people in this [wild +world](https://www.youtube.com/watch?v=84Y9PjfLZZE) that use `guix +shell` the same way I do, so part of the motivation behind this post +is an attempt to get more Guix users to adopt this pattern. + +Oh and finally I should say that I'm not trying to convince anyone to +give up what works for them, be it Docker, Nix, or whatever else. I +don't think anyone is “doing it wrong.” Use what makes you feel +productive and hack the good hack. This is just how I do it. |