
A packaging tutorial for Guix - _emacsomancer_
https://www.gnu.org/software/guix/blog/2018/a-packaging-tutorial-for-guix/
======
VLM
I like the idea a lot, although the kind of people who don't like shell
scripts for init would likely flip completely out at packages using guile lisp
rather than some obscure DSL, and then parenthesis-ophobes are going to react
very poorly to the libgit2 extended example ending in four closing
parenthesis. A little diversity in thought might be a good thing of course.

An init system written entirely in Guile LISP is interesting to think about.
I'm old enough to (barely) remember the 80s lisp machines and since all modern
CS/IT progress is re-implementing stuff from four decades ago, we're about due
for something like linux ported from C to clojure or another lisp with a new
init and the guix packaging system written in guile-scheme-lisp. The idea of
an OS written to run on a JVM instead of virtualization like vmware is
intriguing. I can come up with enough bright ideas in five minutes to keep me
busy for fifty years, so this daydreaming is all very unlikely to happen.

~~~
cygx
_An init system written entirely in Guile LISP is interesting to think about_

[https://www.gnu.org/software/shepherd/](https://www.gnu.org/software/shepherd/)

~~~
flukus
From the documentation:

> The daemon that runs in the background and is responsible for controlling
> the services is shepherd, while the user interface tool is called herd: it’s
> the command that allows you to actually herd your daemons

It seems strange the the herd controls the shepherd, but I guess it fits in
well with GNU's user empowerment philosophy.

I'm very much a parenthesis-ophobe, but things like init configuration is a
niche guile seems to be perfect for. It's terse enough to replace ini's, it's
complex enough to provide structure like xml or json, it's an actual language
so no one ends up writing their own and it's trivial to embed, like like lua.

~~~
_emacsomancer_
I always thought of the `herd` command as a verb (i.e. what do shepherds do?
they `herd` things [well, sheep, I suppose]).

------
iwakura
I always appreciate more documentation when it comes to Nix and Guix. Being
still somewhat new to Nix and Guix I found myself looking up other people's
declarations on Github because the official documentation was lacking.

------
grewil2
Recently I have gotten very interested in Guix, after 16 years of only Debian.
Guix keeps surprising me, most recently its container system. This page is
exactly what I was looking for to get started with my own packages.

~~~
amirouche
Why are you surprised by the container system ?

------
equalunique
Packaging GNU hello is also a focus of examples in the NixPkgs manual[0]. With
this Guix tutorial, there is now a litte more pairity between two great tools.

[0] [https://nixos.org/nixpkgs/manual/](https://nixos.org/nixpkgs/manual/)

~~~
yepguy
Speaking of parity, while the Guix project may have some catching up to do in
general, I think their documentation has been superior to Nix for a while.

~~~
josteink
Nix IMO suffers greatly from... using its own weird own language and DSL (Nix)
which has its own weird semantics.

I tried NixOS and was even willing to author packages to get stuff I needed
working, but I could never wrap my head around the Nix-language.

Guix however, that’s just LISP and there’s few things simpler than that in the
entirety of the programming-universe.

IOW you don’t have to learn something new, or get new editor plugins or
whatever.

I really want Guix to succeed. Here’s me hoping they won’t hamstring it over
licensing issues like the FSF often does.

------
AceJohnny2
I recently realized that Macports package definition files, Portfiles [1], are
actually just TCL. It _looks_ declarative, but that's just because they
defined the functions well (and that's how TCL syntax works)

And "Portgroups" are effectively libraries for the packaging system, so that
they can easily interface with GitHub, CMake, gobject_introspection, etc...

[1] [https://github.com/macports/macports-
ports](https://github.com/macports/macports-ports)

------
nrclark
It's neat how similar this looks to a Bitbake recipe (used by the Yocto Linux
project), except that those are written in a DSL that's half Python and half
shell-script.

Check out a similar recipe here [https://github.com/openembedded/openembedded-
core/blob/maste...](https://github.com/openembedded/openembedded-
core/blob/master/meta/recipes-extended/bc/bc_1.07.1.bb)

------
CJefferson
My main problem with guix, and nix, and debs (the 3 i have tried is they are
great for software wrapped using automake/autoconf, but I can never figure out
how to package things using a custom build system.

~~~
chriswarbo
Guix and Nix just run scripts. I've less experience with Guix, but in Nix you
can just run a bash script which stores the build products in a path given as
`$out`. For example, the following is a perfectly valid Nix package, if we
replaced the nonsense names and commands:

    
    
        with import <nixpkgs> {};
        runCommand "package-name-goes-here"
          {
            buildInputs = [ build tools go here ];
            envVar1 = "hello";
            envVar2 = "world";
          }
          ''
            bash command 1
            bash command 2
            mv my-amazing-output "$out"
          ''
    

For example, I've never written any Go, but I was able to package some Go
programs by copy-pasting their install instructions into the above template
and putting the relevant build tools into `buildInputs`:
[https://github.com/Warbo/warbo-
packages/blob/master/packages...](https://github.com/Warbo/warbo-
packages/blob/master/packages/goat.nix)

In contrast, the automake/autoconf support is actually a _very_ complicated
tower of helper scripts, override hooks, etc. which is built up on top of the
system's built in support for running bash scripts (actually it runs whatever
we call `builder` with whatever we call `args`; `runCommand` sets the
`builder` to be bash and the `args` to be a file containing our script).

~~~
rekado
While Guix eventually runs a builder script, the script is 1) a Guile script
and 2) not directly provided by the user but the result of compilation.

Guix does not stitch shell scripts together. Builds in Guix are split into
build phases, which are Guile procedures. Build system abstractions are
collections of these procedures. A packager can inject additional build phases
or delete existing build phases from these build systems on a package by
package basis.

The `trivial-build-system` is used for packages where none of the existing
build systems are applicable, not even with build phases removed or added.
This works but is not used very often as it is often more convenient to start
with something like the `gnu-build-system` and to replace phases by providing
new procedures; this is done to benefit from build phases that the `gnu-build-
system` provides, such as those that unpack the sources, patch shebangs, or
validate the binaries.

~~~
chriswarbo
Thanks for the Guix info, as I say I've not really used it. The use of
"phases", etc. is what I was getting at w.r.t. Nix's complicated
"autoconf/automake support" (AKA `stdenv.mkDerivation`).

As you say, Guix's use of Scheme rather than stiching shell scripts together
should be more powerful (in particular, concatenating strings of bash results
in a rather opaque builder; whilst a more declarative s-expression approach
would make traversing and modifying the builder more feasible)

