Guix tutorial, using, creating, contributing

GNU Guix is what they call a 'functional package manager'. Think as if git and apt-get had a child. It allows you to do transactional rollbacks or have multiple versions of the same app coexisting. Probably if you're here you already know what's GNU Guix, so I won't bother explaining it again. Visit the official page if you need more info.

To contribute to Guix, you'll have to have a few dependencies installed, and after that, follow a few steps which I'll try to explain in here, as the documentation that's now on the guix site is quite scarce (for newbies at least).

There are a few more steps than in most applications, so I'll put them here. 

- Install guix. Download the git version from git clone git://git.savannah.gnu.org/guix.git. Then, ./bootstrap && ./configure && make # make install is optional
- Create users. Follow these instructions to create some build users.
- Create the package store. mkdir /nix/store
- Create ~/.guix-profile. This should be created by guix-deamon itself.
- Put ~/.guix-profile in $PATH.

 

 Basic commands 

 

To run any guix command, you should have the guix server running. When you run guix commands, the client will connect to the daemon, and will run the command itself.

We'll try to install and run a test demo that guix users use as a minimal test. It's a helloworld app.

- Run server.  ./pre-inst-env guix-daemon --build-users-group=guix-builder
- Search package.  ./pre-inst-env scripts/guix package -s hello
- Install package. ./pre-inst-env scripts/guix package -i hello
- Run hello. The hello app should be in your $PATH.
- Remove package. ./pre-inst-env scripts/guix package -r hello

If you installed Guix system-wide (make install), ./pre-inst-env is not needed.

Guix Recipes

If you're trying to write a recipe for guix, here are the steps to follow, and good practices.

First, let's see what's in the 'hello' recipe, and try to understand it. then, we'll add a few things to make it build something more interesting. The file is in gnu/packages/base.scm, so when we open it we see something like this:

We can see a few interesting lines there. Even if you have no scheme knowledge, you can find out what's going on there.  The name and version of the package in some places, the url (mirror:// means "download from any gnu mirror", but could be just a normal URL), description of the package.

The hash code in the sexp (sha256 (base32   "19qy37gkasc4csb1d3bdiz9snn8mir2p3aj0jgzmfv0r2hi7mfzc")) is a checksum of the downloaded file. You can get that number using

./pre-inst-env scripts/guix download URL or
./pre-inst-env scripts/guix hash FILE.

 

 Example Recipe

As an example, we'll build a relatively simple package, luajit.

In guix, recipes are organized in files, but not necessarily one recipe per file.  When I wrote the luajit recipe, lua.scm already existed, so it made sense to put it in the same file.  If we add a new file, we should add the file in the file gnu-system.am .

Although having different presets for different build systems, many packages need some special tweaking.

here we added PREFIX variable in make phase, and we removed configure phase and test.

Guix installations happen in phases, usng alist-delete we can remove one of them.

We can try the build by using ./pre-inst-env scripts/guix build luajit.  If everything is ok, we can submit the patch.

 

 Sending the patch

If the recipe built correctly, and you can install the package, that's the time for sending the recipe.

Make a commit with the recipe. The commit message should start with 'gnu:', and follow the GNU commit guidelines.

$ git format-patch -1 HEAD #will make a patch for the latest commit.

Send the patch to the mail list.

 

Addendum: Comunity

The community is also important in Free software projects. And this one is really nice. It's small but very helpful. If you have questions, don't hesitate asking in #guix on freenode or in the guix mail list.  Here's an example of a recent conversation I had with Ludovic (the main author of the project)
Neat, no? :)