So, given the fast-paced world of Linux container development and the
companies investing huge sums of money into the aformentioned tools,
why add another implementation to the mix? What’s wrong with the
status quo? What can Guix possibly add? Let’s dive into the
motivation behind Guix containers, how they differ from the status
quo, and how they solve issues that other implementations cannot.

From the blog dthompson by David Thompson and used with permission of the author. All other rights reserved by the author.

Taking a step back, it becomes apparent that dependency isolation is a
general problem that isn’t confined to software written in Ruby: Node
has npm and nvm, Python has pip and virtualenv, and so on. A big
limitation of all these language-specific package managers is that
they cannot control what is outside of their language domain. In
order to use RVM to successfully compile a version of Ruby, you need
to make sure you have the GCC toolchain, OpenSSL, readline, libffi,
etc. installed using the system package manager (note: I’ve seen RVM
try to build prerequisites like OpenSSL before, which I then disabled
to avoid duplication and security issues and I recommend you do the
same.) In order to use Bundler to install Nokogiri, you need to make
sure libxml2 has been installed using the system package manager. If
you work with more than a single language, the number of different
package management tools needed to get work done is staggering. For
web applications, it’s not uncommon to use RVM, Bundler, NPM, Bower,
and the system package manager simultaneously to get all of the
necessary programs and libraries. Large web applications are
notoriously difficult to deploy, and companies hire a bunch of
operations folk like me to try to wrangle it all.

Anyway, let’s forget about Node, Python, etc. and just focus on Ruby.
Have you or someone you work with encountered hard to debug issues and
Git merge conflicts due to a problem with Gemfile.lock? Bundler’s
fast and loose versioning in the Gemfile (e.g. rails >= 4.0)
causes headaches when different users update different gems at
different times and check the resulting auto-generated
Gemfile.lock into the repository. Have you ever been frustrated
that it’s difficult to deduplicate gems that are shared between
multiple bundled gem sets? Have you looked at the RVM home page
and been frustrated that they recommend you to curl | bash to
install their software? Have you been annoyed by RVM’s strange system
of overriding shell built-ins in order to work its magic? I’m not
sure how you feel, dear reader, but my Ruby environments feel like one
giant, brittle hack, and I’m often enough involved in fixing issues
with them on my own workstation, that of my colleagues, and on
production servers.

So, if you’re still with me, what do we do about this? How can we
work to improve upon the status quo? Just use Docker? Docker is
helpful, and certainly much better than no isolation at all, but it
hides the flaws of package management inside an opaque disk image and
restricts the environments in which your application is built to
function. The general problem of dependency isolation is orthogonal
to the runtime environment, be it container, virtual machine, or "bare
metal." Enter functional package management. What does it mean for a
package manager to be functional? GNU Guix, the functional package
manager that I contribute to and recommend, has this to say:

GNU Guix is a functional package management tool for the GNU
system. Package management consists of all activities that relate
to building packages from sources, honoring their build-time and
run-time dependencies, installing packages in user environments,
upgrading installed packages to new versions or rolling back to a
previous set, removing unused software packages, etc.

The term functional refers to a specific package management
discipline. In Guix, the package build and installation process
is seen as a function, in the mathematical sense. That function
takes inputs, such as build scripts, a compiler, and libraries,
and returns an installed package.

Guix has a rich set of features, some of which you may find in other
package managers, but not all of them (unless you use another
functional package manager such as Nix.) Gem/Bundler can do
unprivileged gem installation, but it cannot do transactional upgrades
and rollbacks or install non-Ruby dependencies. Dpkg/yum/pacman can
install all build-time and rumtime dependencies, but it cannot do
unprivileged package installation to isolated user environments. And
none of them can precisely describe the full dependency graph (all
the way down to the C compiler’s compiler) but Guix can.

Guix is written in Guile, an implementation of the Scheme programming
language. The upcoming release of Guix will feature a Ruby build
system that captures the process of installing gems from .gem
archives and a RubyGems import utility to make it easier to write Guix
packages by using the metadata available on https://rubygems.org.
Ruby developers interested in functional package management are
encouraged to try packaging their gems (and dependencies) for Guix.

Now, how exactly can Guix replace RVM and Bundler? Guix uses an
abstraction called a "profile" that represents a user-defined set of
packages that should work together. Think of it as having many
/usr file system trees that can be used in isolation from the
others (without invoking virtualization technologies such as virtual
machines or containers.) To install multiple versions of Ruby and
various gems, the user need only create a separate profile for them:

guix package --profile=project-1 --install ruby-2.2 ruby-rspec-3
# Hypothetical packages:
guix package --profile=project-2 --install ruby-1.9 ruby-rspec-2

A profile is a "symlink forest" that is the union of all the packages
it includes, and files are deduplicated among all of them. To
actually use the profile, the relevant environment variables must be
configured. Guix is aware of such variables, and can tell you what to
set by running the following:

guix package --search-paths --profile=project-1

Additionally, you can also create ad-hoc development environments with
the guix environment tool. This tool will spawn a sub-shell (or
another program of your choice) in an environment in which a set of
specified packages are available. This is my preferred method as it
automagically sets all of the environment variables for me and Guix is
free to garbage collect the packages when I close the sub-shell:

# Launch a Ruby REPL with ActiveSupport available.
guix environment --ad-hoc ruby ruby-activesupport -E irb

In order to make this environment reproducible for others, I recommend
keeping a package.scm file in version control that describes the
complete dependency graph for your project, as well as metadata such
as the license, version, and description:

(use-modules (guix packages)
             (guix licenses)
             (guix build-system ruby)
             (gnu packages)
             (gnu packages version-control)
             (gnu packages ssh)
             (gnu packages ruby))

(package
  (name "cool-ruby-project")
  (version "1.0")
  (source #f) ; not needed just to create dev environment
  (build-system ruby-build-system)
  ;; These correspond roughly to "development" dependencies.
  (native-inputs
   `(("git" ,git)
     ("openssh" ,openssh)
     ("ruby-rspec" ,ruby-rspec)))
  (propagated-inputs
   `(("ruby-pg" ,ruby-pg)
     ("ruby-nokogiri" ,ruby-nokogiri)
     ("ruby-i18n" ,ruby-i18n)
     ("ruby-rails" ,ruby-rails)))
  (synopsis "A cool Ruby project")
  (description "This software does some cool stuff, trust me.")
  (home-page "https://example.com")
  (license expat))

With this package file, it is simple to an instantiate a development
environment:

guix environment -l package.scm

I’m not covering it in this post, but properly filling out the blank
source field above would allow for building development snapshots,
including running the test suite, in an isolated build container using
the guix build utility. This is a very useful when composed with
a continuous integration system. Guix itself uses Hydra as its CI
system to perform all package builds.

As mentioned earlier, one of the big advantages of writing Guix
package recipes is that the full dependency graph can be captured,
including non-Ruby components. The pg gem provides a good example:

(define-public ruby-pg
  (package
    (name "ruby-pg")
    (version "0.18.2")
    (source
     (origin
       (method url-fetch)
       (uri (rubygems-uri "pg" version))
       (sha256
        (base32
         "1axxbf6ij1iqi3i1r3asvjc80b0py5bz0m2wy5kdi5xkrpr82kpf"))))
    (build-system ruby-build-system)
    (arguments
     '(#:test-target "spec"))
    ;; Native inputs are used only at build and test time.
    (native-inputs
     `(("ruby-rake-compiler" ,ruby-rake-compiler)
       ("ruby-hoe" ,ruby-hoe)
       ("ruby-rspec" ,ruby-rspec)))
    ;; Native extension links against PostgreSQL shared library.
    (inputs
     `(("postgresql" ,postgresql)))
    (synopsis "Ruby interface to PostgreSQL")
    (description "Pg is the Ruby interface to the PostgreSQL RDBMS.  It works
with PostgreSQL 8.4 and later.")
    (home-page "https://bitbucket.org/ged/ruby-pg")
    (license license:ruby)))

Note how the recipe specifies the PostgreSQL dependency. Below is the
dependency graph for ruby-pg as produced by guix graph, excluding
the GCC compiler toolchain and other low-level tools for brevity.
Pretty neat, eh?

Given that Guix doesn’t yet have many gems packaged (help wanted), it
can still be advantageous to use it for getting more up-to-date
packages than many distros provide, but in conjuction with Bundler for
fetching Ruby gems. This gets RVM out of your hair whilst creating a
migration path away from Bundler at a later time once the required
gems have been packaged:

cd my-project/
guix environment --ad-hoc ruby bundler libxml2 libxslt # etc.
# A small bash script can be used to make these gem sets.
mkdir .gems
export GEM_HOME=$PWD/.gems
export GEM_PATH=$GEM_HOME:$GEM_PATH
export PATH=$GEM_HOME/bin:$PATH
bundle install

As you’ve seen in the above package snippets, Guix package definitions
are typically very short and rather easy to write yourself. The
guix import gem tool was made to lower the barrier even more by
generating most of the boilerplate code. For example:

guix import gem pry

Produces this Scheme code:

(package
  (name "ruby-pry")
  (version "0.10.1")
  (source
    (origin
      (method url-fetch)
      (uri (rubygems-uri "pry" version))
      (sha256
        (base32
          "1j0r5fm0wvdwzbh6d6apnp7c0n150hpm9zxpm5xvcgfqr36jaj8z"))))
  (build-system ruby-build-system)
  (propagated-inputs
    `(("ruby-coderay" ,ruby-coderay)
      ("ruby-method-source" ,ruby-method-source)
      ("ruby-slop" ,ruby-slop)))
  (synopsis
    "An IRB alternative and runtime developer console")
  (description
    "An IRB alternative and runtime developer console")
  (home-page "http://pryrepl.org")
  (license expat))

One still has to package the propagated inputs if they aren’t yet
available, add the necessary inputs for building native extensions if
needed, and fiddle with the native inputs needed to run the test
suite, but for most pure Ruby gems this gets you close to a working
package quickly.

In conclusion, while support for Ruby in Guix is still in its early
days, I hope that you have seen the benefits that using a
general-purpose, functional package manager can bring to your Ruby
environments (and all other environments, too.) For more information
about Guix concepts, installation instructions, programming interface,
and tools, please refer to the official manual. Check out the
help page for ways to contact the development team for help or to
report bugs. If you are interested in getting your hands dirty,
please contribute. Besides contributions of code, art, and docs,
we also need hardware donations to grow our build farm to meet the
needs of all our users. Happy hacking!

From the blog dthompson by David Thompson and used with permission of the author. All other rights reserved by the author.

guix environment is a new utility added in Guix 0.8, which should
be released in a few weeks. It accepts one on more packages as input
and produces a new shell environment in which all of the dependencies
for those packages are made available. For example, guix
environment emacs will get you everything you need to build GNU
Emacs from a source release tarball. By default, your $SHELL is
spawned, but you may opt to use any arbitrary shell command instead.
If you’ve used Nix before, you may notice that this sounds exactly
like nix-shell, and that’s because it was what inspired me to
write guix environment.

Now, let’s take a look at an example. One of my hobby projects is
Sly, a game engine written in Guile Scheme. Here’s the relevant Guix
code that will produce a complete development environment:

;;; Copyright (C) 2014 David Thompson <davet@gnu.org>
;;;
;;; Sly is free software: you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation, either version 3 of the License, or
;;; (at your option) any later version.

(use-modules (guix packages)
             (guix licenses)
             (guix build-system gnu)
             (gnu packages)
             (gnu packages autotools)
             (gnu packages guile)
             (gnu packages gl)
             (gnu packages pkg-config)
             (gnu packages sdl)
             (gnu packages maths)
             (gnu packages image))

;; The development environment needs a tweaked LD_LIBRARY_PATH for
;; finding libfreeimage.
(define freeimage
  (package (inherit freeimage)
    (native-search-paths
     (list (search-path-specification
            (variable "LD_LIBRARY_PATH")
            (directories '("lib")))))))

(package
  (name "sly")
  (version "0.0")
  (source #f)
  (build-system gnu-build-system)
  (inputs
   `(("pkg-config" ,pkg-config)
     ("autoconf" ,autoconf)
     ("automake" ,automake)
     ("guile" ,guile-2.0)
     ("guile-sdl" ,guile-sdl)
     ("guile-opengl" ,guile-opengl)
     ("gsl" ,gsl)
     ("freeimage" ,freeimage)
     ("mesa" ,mesa)))
  (synopsis "2D/3D game engine for GNU Guile")
  (description "Sly is a 2D/3D game engine written in Guile Scheme.
Sly differs from most game engines in that it emphasizes functional
reactive programming and live coding.")
  (home-page "https://gitorious.org/sly/sly")
  (license gpl3+))

You may have noticed that the source field has been set to false.
This is because the package is not for building and installing. It’s
sole purpose is to provide the necessary software needed to build Sly
from a fresh git checkout.

Assuming this code is in a file called package.scm, you can simply
run guix environment -l package.scm to spawn a shell for hacking
on Sly. By default, the environment created is an augmented version
of your pre-existing shell’s environment. This is convenient when you
want to use your installed software in the new environment, such as
git. However, it’s important to make sure that the environment really
does have everything needed for development without relying on any
impurities introduced by your existing environment. Without verifying
this, new developers might be frustrated to find out that the
environment provided to them is incomplete. To verify, pass the
--pure flag and build from scratch.

So, guix environment is a pretty nice way to acquire all the
dependencies you need to work on a project, but there is still a lot
of room for improvement. What if you were working on a web
application that required a running PostgreSQL database, Redis server,
and XMPP server? It would be really great if Guix could handle
setting this up for you, too, a la Vagrant. To do so, guix
environment could use the existing features of guix system to
spawn a new virtual machine that shared the host system’s package
store and the project’s source tree, and then spawn a shell with your
development environment. I hope to implement this in the
not-too-distant future. Until next time, happy hacking!

From the blog dthompson by David Thompson and used with permission of the author. All other rights reserved by the author.

(alist->hash-table
 '((foo . 1)
   (bar . 2)
   (baz . 3)))

However, I prefer to use Guile’s native hash implementation, and
SRFI-69 is incompatible with it, so I decided to port
alist->hash-table. Unfortunately, it was not as simple as writing
just one procedure. The native hash tables actually have 4 different
ways of doing key comparisons: Using equal?, eq?, eqv?,
and user-defined procedures. This is a design flaw because the user
must make sure to use the right procedures at all times rather than
simply set the hash and assoc procedures when creating the
hash table instance.

Below is the final implementation. Since 3 of the 4 variations were
essentially the same, I wrote a short macro to reduce code
duplication.

;;;; Copyright (C) 2013 Free Software Foundation, Inc.
;;;;
;;;; This library is free software; you can redistribute it and/or
;;;; modify it under the terms of the GNU Lesser General Public
;;;; License as published by the Free Software Foundation; either
;;;; version 3 of the License, or (at your option) any later version.
;;;;
;;;; This library is distributed in the hope that it will be useful,
;;;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
;;;; Lesser General Public License for more details.
;;;;
;;;; You should have received a copy of the GNU Lesser General Public
;;;; License along with this library; if not, write to the Free Software
;;;; Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
;;;;

(define-syntax-rule (define-alist-converter name hash-set-proc)
  (define (name alist)
    "Convert ALIST into a hash table."
    (let ((table (make-hash-table)))
      (for-each (lambda (pair)
                  (hash-set-proc table (car pair) (cdr pair)))
                (reverse alist))
      table)))

(define-alist-converter alist->hash-table hash-set!)
(define-alist-converter alist->hashq-table hashq-set!)
(define-alist-converter alist->hashv-table hashv-set!)

(define (alist->hashx-table hash assoc alist)
  "Convert ALIST into a hash table with custom HASH and ASSOC
procedures."
  (let ((table (make-hash-table)))
    (for-each (lambda (pair)
                (hashx-set! hash assoc table (car pair) (cdr pair)))
              (reverse alist))
    table))

Not only did I manage to get my code into Guile, I was given commit
access to GNU Guix by the lead developer, Ludovic Courtès. I have
never had commit access to any free software project repositories
besides my own. I feel quite honored, as cheesy as that may sound.

Packages for SDL and SDL2 have been merged into master, and packages
for SDL_gfx, SDL_image, SDL_mixer, SDL_net, and SDL_ttf for SDL 1.2
are pending review.

I like to show off the elegance of Guix package recipes, so here’s
some code:

;;; Copyright © 2013 David Thompson <dthompson2@worcester.edu>
;;;
;;; This file is part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.

(define sdl
  (package
    (name "sdl")
    (version "1.2.15")
    (source (origin
             (method url-fetch)
             (uri
              (string-append "http://libsdl.org/release/SDL-"
                             version ".tar.gz"))
             (sha256
              (base32
               "005d993xcac8236fpvd1iawkz4wqjybkpn8dbwaliqz5jfkidlyn"))))
    (build-system gnu-build-system)
    (arguments '(#:tests? #f)) ; no check target
    (inputs `(("libx11" ,libx11)
              ("libxrandr" ,libxrandr)
              ("mesa" ,mesa)
              ("alsa-lib" ,alsa-lib)
              ("pkg-config" ,pkg-config)
              ("pulseaudio" ,pulseaudio)))
    (synopsis "Cross platform game development library")
    (description "Simple DirectMedia Layer is a cross-platform development
library designed to provide low level access to audio, keyboard, mouse,
joystick, and graphics hardware.")
    (home-page "http://libsdl.org/")
    (license lgpl2.1)))

(define sdl2
  (package (inherit sdl)
    (name "sdl2")
    (version "2.0.0")
    (source (origin
             (method url-fetch)
             (uri
              (string-append "http://libsdl.org/release/SDL2-"
                             version ".tar.gz"))
             (sha256
              (base32
               "0y3in99brki7vc2mb4c0w39v70mf4h341mblhh8nmq4h7lawhskg"))))
    (license bsd-3)))

Much help is needed to package the GNU system for Guix. If you are
interested in helping, please drop by #guix on freenode, we are
friendly.

From the blog dthompson by David Thompson and used with permission of the author. All other rights reserved by the author.

I was told that libtheora would be pretty easy to package, and it
was. Here’s what the package definition looks like:

(define libtheora
  (package
    (name "libtheora")
    (version "1.1.1")
    (source (origin
             (method url-fetch)
             (uri (string-append "http://downloads.xiph.org/releases/theora/libtheora-"
                                 version ".tar.xz"))
             (sha256
              (base32
               "0q8wark9ribij57dciym5vdikg2464p8q2mgqvfb78ksjh4s8vgk"))))
    (build-system gnu-build-system)
    (inputs `(("libvorbis" ,libvorbis)))
    ;; The .pc files refer to libogg.
    (propagated-inputs `(("libogg" ,libogg)))
    (synopsis "Library implementing the Theora video format")
    (description
     "The libtheora library implements the ogg theora video format,
a fully open, non-proprietary, patent-and-royalty-free, general-purpose
compressed video format.")
    (license license:bsd-3)
    (home-page "http://xiph.org/theora/")))

Pretty slick, eh? Now, I’m starting to work on packaging SDL (1.2
and 2) and the SDL extensions (gfx, ttf, etc.), which are not quite as
easy. I hope to package all of the dependencies that guile-2d will
need to be available as a Guix package.

From the blog dthompson by David Thompson and used with permission of the author. All other rights reserved by the author.