6 ms·

A packaging tutorial for Guix

130 points by _emacsomancer_ 8y ago

equalunique 8y ago
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 8y ago
  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 8y ago
    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.
iwakura 8y ago
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.
VLM 8y ago
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.
- _emacsomancer_ 8y ago
  > 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 Do you mean people used to systemd specifically or does this also include runit, s6, etc.? > parenthesis-ophobes are going to react very poorly to the libgit2 extended example ending in four closing parentheses Though, of course, for humans reading Lisp, the trick is not to focus on the parentheses too much, but use the indentation. And then use the parentheses as a sort of double-sanity check as you move your editor's point/cursor across them and see the other member of the pair light up (assuming a sane lisp editor/editor configuration). (And maybe: parenthephobes?)
- cygx 8y ago
  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/
  - _emacsomancer_ 8y ago
    And Shepherd is very pleasant to interact with.
  - flukus 8y ago
    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_ 8y ago
      I always thought of the `herd` command as a verb (i.e. what do shepherds do? they `herd` things [well, sheep, I suppose]).
CJefferson 8y ago
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.
- cstrahan 8y ago
  It's certainly doable. I contributed Envoy to Nixpkgs (built with bazel) and developed the current incarnation of the RubyGems/Bundler build infrastructure.
- chriswarbo 8y ago
  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/goat.nix https://github.com/Warbo/warbo-packages/blob/master/packages... 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 8y ago
    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.
AceJohnny2 8y ago
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 8y ago
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/master/meta/recipes-extended/bc/bc_1.07.1.bb https://github.com/openembedded/openembedded-core/blob/maste...
grewil2 8y ago
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 8y ago
  Why are you surprised by the container system ?

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 8y ago
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 8y ago
  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.

iwakura 8y ago

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.

VLM 8y ago

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.

_emacsomancer_ 8y ago
> 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 Do you mean people used to systemd specifically or does this also include runit, s6, etc.? > parenthesis-ophobes are going to react very poorly to the libgit2 extended example ending in four closing parentheses Though, of course, for humans reading Lisp, the trick is not to focus on the parentheses too much, but use the indentation. And then use the parentheses as a sort of double-sanity check as you move your editor's point/cursor across them and see the other member of the pair light up (assuming a sane lisp editor/editor configuration). (And maybe: parenthephobes?)
cygx 8y ago
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/
- _emacsomancer_ 8y ago
  And Shepherd is very pleasant to interact with.
- flukus 8y ago
  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_ 8y ago
    I always thought of the `herd` command as a verb (i.e. what do shepherds do? they `herd` things [well, sheep, I suppose]).

CJefferson 8y ago

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.

cstrahan 8y ago
It's certainly doable. I contributed Envoy to Nixpkgs (built with bazel) and developed the current incarnation of the RubyGems/Bundler build infrastructure.
chriswarbo 8y ago
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/goat.nix https://github.com/Warbo/warbo-packages/blob/master/packages... 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 8y ago
  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.

AceJohnny2 8y ago

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 8y ago

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/master/meta/recipes-extended/bc/bc_1.07.1.bb https://github.com/openembedded/openembedded-core/blob/maste...

grewil2 8y ago

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 8y ago
Why are you surprised by the container system ?