We like to say that Docker images are like smoothies: you can immediately tell whether it’s your liking, but you can hardly guess what the ingredients are. Although containers are an efficient way to ship things, the core question is how these things are produced.
The guix pack
command creates “application bundles” that can be used to deploy
software on machines that do not run Guix (yet!), such as HPC clusters. Since
its inception in
2017,
it has seen a number of improvements, such as the ability to create
Docker and Singularity container images. Some clusters lack these
tools, though, and the addition of relocatable
packs
was a way to address that. This post looks at a new execution engine
for relocatable packs that has just
landed with the goal of improving
performance.
In the previous
post, we saw that
Guix’s build daemon needs to run as root, and for a good reason:
that’s currently the only way to create isolated build environments for
packages on GNU/Linux. This requirement means that you cannot use Guix
on a cluster where the sysadmins have not already installed it. In this
article, we discuss how to take advantage of Guix on clusters that lack
a proper Guix installation.
Guix is a good fit for multi-user environments such as clusters:
it
allows non-root users to install packages at will without interfering with each other.
However, a common complaint is that installing Guix requires administrator
privileges. More precisely, guix-daemon, the system-wide daemon that
spawns package builds and downloads on behalf of
users,
must be running as root.
This is not much of a problem on one's laptop but it surely makes it
harder to adopt Guix on an HPC cluster.
