[Nix-dev] [***SPAM***] [ANN] Guix, functional package management from Guile

[Sander van der Burg - EWI]

Awesome experiment Ludovic!

Actually, I had some "crazy ideas" in the past as well. For example, to develop an "internal DSL" for Nix in Scala (no specific reason why it's useful, but oh well....)
________________________________________
From: nix-dev-bounces at lists.science.uu.nl [nix-dev-bounces at lists.science.uu.nl] on behalf of Ludovic Courtès [ludo at gnu.org]
Sent: Saturday, July 07, 2012 11:55 PM
To: guile-user at gnu.org; gnu-system-discuss at gnu.org; nix-dev
Subject: [Nix-dev] [***SPAM***] [ANN] Guix,     functional package management from Guile

Hello!

I am delighted to announce Guix, a purely functional package
management tool.

  https://gitorious.org/guix

  http://www.fdn.fr/~lcourtes/software/guix-0.0.tar.gz
  SHA1: 30d99946c67e9a015bb9817b3731765aadc533be

Guix is written in Guile Scheme.  It builds on top of the low-level
build and storage mechanisms of the Nix package manager[*], and provides
high-level APIs to describe and run arbitrary build processes, and a
declarative interface to describe and compose software packages.

Guix implements purely functional package build and composition: a build
process is a Scheme function that returns the path of its result in the
“store”–the /nix/store directory.  The store acts as a build cache,
subject to garbage collection.  Changing a bit in the build process’s
inputs (dependencies, environment variables, etc.) changes the result.

All the nifty features of Nix are inherited:

  • multiple versions or variants of packages can happily coexist;

  • the package build environment is under control, in a chroot, such
    that the result of a build process cannot be influenced by the
    outside world;

  • support for transactional upgrades and rollback;

  • per-user environments, non-root package installation;

  • etc.


Last but not least, Guix comes with an actual distro!

  https://gitorious.org/guix/guix/blobs/master/distro/base.scm

Granted, it has yet to grow ;-), but it showcases the main ideas:
packages are described in a high-level, hopefully intelligible way, and
their build scripts are written and customized in Scheme.  Packages may
be built with, say:

  guix-build guile

or

  guix-build -e '(@ (distro base) guile-2.0)'

The latter refers unambiguously to the variable bound to the package of
interest, whereas the former would pick the first package of that name.

The ‘guile-reader’ example in the above file shows package composition,
while the ‘lout’ example shows that even hostile build systems can be
accommodated.


Guix & Nix
~~~~~~~~~~

Nix is really two things: a package build tool, implemented by a library
and daemon, and a special-purpose programming language.  Guix relies on
the former, but uses Scheme as a replacement for the latter.

Technically, Guix makes remote procedure calls to the ‘nix-worker’
daemon to perform operations on the store.  At the lowest level, Nix
“derivations” represent promises of a build, stored in ‘.drv’ files in
the store.  Guix produces such derivations, which are then interpreted
by the daemon to perform the build.  Thus, Guix derivations can use
derivations produced by Nix (and vice versa); in Guix, the cheat code is
the ‘nixpkgs-derivation’ procedure.  :-)

With Nix and the Nixpkgs distribution, package composition happens at
the Nix language level, but builders are usually written in Bash.
Conversely, Guix encourages the use of Scheme for both package
composition and builders.

Other noteworthy points: Guix doesn’t yet have an equivalent to
‘nix-env’; it supports multiple-derivation outputs (where a build
produces several files under /nix/store); package descriptions in the
mini-distro are internationalized; the distribution being written in
Scheme, it is compiled efficiently by Guile’s compiler.


Help needed!
~~~~~~~~~~~~

It seems to me like a lot more can be done with this, and it’s fun!

If you’re a Nixer, you’re welcome to give it a try (you just need a
‘nix-worker’ instance running), attempt to build/package something, and
provide feedback on the API and declarative package expressions.

If you’re a Guiler, there are interesting challenges.  One is to write
more macros/EDSLs to provide builders with operations as high-level as
typically found in shell scripts (for instance, ‘substitute*’ attempts
to provide a sed-like API.)  Another one is to investigate whether/how
the code of builders could be generated hygienically (see
‘build-expression->derivation’.)

If you’re a GNU-system-discusser, feedback is welcome!  How would it fit
in a hypothetical GNU distribution?

Happy hacking & packaging!
Ludo’.

[*] http://nixos.org/nix/