[ANN] Guix, functional package management from Guile

[ANN] Guix, functional package management from Guile

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 4248 bytes --]

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/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [***SPAM***] [ANN] Guix, functional package management from Guile

[Shea Levy]

Hi Ludo,

Very cool work, I'll have to check it out. One queston and one quick note:

On Jul 7, 2012, at 5:55 PM, ludo@gnu.org (Ludovic Courtès) wrote:

> in Guix, the cheat code is
> the ‘nixpkgs-derivation’ procedure.  :-)

Does the referenced derivation need to actually be in nixpkgs? I assume this works by calling nix-instantiate?

> 
> it supports multiple-derivation outputs (where a build
> produces several files under /nix/store)

Just FYI, multiple-outputs support is not complete at the nix-store level. In particular, if you have one output of a derivation realized but not all (because you gc'd the others or got the one via a substitutor), nix-store can't realize the non-realized ones directly yet. There may be other issues I'm not aware of too.

Cheers,
Shea
_______________________________________________
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [***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@lists.science.uu.nl [nix-dev-bounces@lists.science.uu.nl] on behalf of Ludovic Courtès [ludo@gnu.org]
Sent: Saturday, July 07, 2012 11:55 PM
To: guile-user@gnu.org; gnu-system-discuss@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/