[Nix-dev] Haskell NG
Peter Simons
simons at cryp.to
Fri Dec 12 15:38:11 CET 2014
Hi guys,
in the spirit of "release early, release often", I'd like to inform everyone
with an interest in the Haskell part of Nixpkgs about the ongoing effort to
re-factor both cabal2nix and the code in Nixpkgs to achieve ...
1) support for all of Hackage,
2) death to the ghc-wrapper, and
3) easier and more reliably customization of the package set.
The Nixpkgs code lives in the "haskell-ng" branch of my Github clone [1]. In
that branch, Haskell related code is in pkgs/development/haskell-modules:
- hackage-packages.nix is generated automatically by the "hackage2nix" utility
from the "v2.x" branch of the cabal2nix repository [2]. The file defines
builds for the respective latest version of every Hackage package.
hackage2nix can include some older package versions, too, if necessary. (I
need to add code to hackage2nix to configure the choice of generated
packages conveniently.)
Note that a significant portion of those builds will not succeed because
they depend on system libraries that we don't have. Finding those broken
packages and fixing them (or adding meta.broken = true) will need a
community effort once this setup has stabilized. The Hydra job [3] builds
these packages to give us feedback on the state of affairs.
- default.nix imports the contents from hackage-packages.nix, applies (a
sequence of) configuration functions, and makes the result available as a
"haskellPackages" set suitable for nix-env and friends. The purpose of those
configurations is to adapt the package set for different compiler versions,
i.e. you can think of this file as a simplified version of what used to be
haskell-defaults.nix.
In the new setup, it will no longer be possible to install Haskell libraries
by name: you must access them by their attribute path. This is necessary for
performance reasons, because nix-env won't like us to bring an additional
7000+ packages into scope. The big advantage of this change is that we can
drop all that freaky name-mangling as package names no longer need to be
unique in the global scope.
- generic-builder.nix is a vastly simplified build function for Haskell
packages. It's main feature is that it works with plain GHC -- meaning that
ghc-wrapper is no longer required anywhere in Nixpkgs. Furthermore, builds
are simple non-recursive attribute sets now; there is no more of that
recursive tying-the-knot stuff the old 'cabal' function used to require.
>From the user's point of view, there are two important changes:
1) No more ghc-wrapper, i.e. we no longer support non-deterministic setups
where people install random packages into random places and expect them to
know about each other. Instead, 'ghcWithPackages' is the tool of choice to
create a deterministic Haskell environment. I plan to add support to
cabal2nix for generating appropriate build instructions for use with
nix-shell. It might also be nice to have a tool "nix-cabal-shall" that
combines cabal2nix and nix-shell into one.
2) Haskell packages support 'deepOverride'. Suppose package 'foo' requires a
non-default version of 'binary'. Then
foo.deepOverride { binary = self.binary_0_4_0_1; };
gives a derivation that uses this particular version to build 'foo' as well
as all of foo's build inputs.
The current state of the repository is "work in progress". I don't use this
code for production yet, and neither should you. :-) I just wanted to share the
effort to keep everyone in the loop and to encourage you to provide feedback.
Best regards,
Peter
[1] https://github.com/peti/nixpkgs/tree/haskell-ng
[2] https://github.com/NixOS/cabal2nix/tree/v2.x
[3] http://hydra.nixos.org/jobset/nixpkgs/haskell-updates
More information about the nix-dev
mailing list