git.iko.soy/haskell.nix
on e94de40 help sign in
haskell.nix/docs/motivation.md
80 lines 3.6 kB history raw
1# Motivation
3Why do we need another Haskell infrastructure for Nix?
5Doesn't nixpkgs
6provide a sufficiently good Haskell infrastructure already?
8Problems with
9the nixpkgs haskell infrastructure are covered in the following sections:
11## Cross compilation
13`nixpkgs` has quite good support for cross compilation, however the
14Haskell infrastructure suffers from the fact that it heavily relies on
15the `cabal2nix` tool. `cabal2nix` (as well as tools that depend on it
16like `stack2nix`) flattens the `.cabal` file at conversion time to a
17given os/arch/flags configuration. Thus to make cross compilation
18work with `cabal2nix` you will have to generate a separate `nix`
19expression for each configuration. This becomes a major maintenance
20burden over time. Therefore the tooling that translates cabal files
21into nix-expressions for use with Haskell.nix retains the full
22conditional tree from the cabal file and exposes it to `nix`. In
23addition it will also expose the `build-type` value, which allows us
24to cache the `Setup.hs` for build-type simple and not have to rebuild
25it every time.
27## Package sets
29We often rely on either package sets as provided by stackage or
30computed by cabal. `nixpkgs` provides its own curated package set
31which might or might not work for the projects we work on.
32`stack2nix` tries to solve this issue, here we go one step further and
33provide the infrastructure to allow any form of package set.
35## Per component level control
37The Haskell builder in `nixpkgs` provides control over executables and
38libraries, to build a specific executable only however is rather
39tricky to do. This also leads to the cyclic dependencies issue.
41## Cyclic dependencies
43The Haskell builder in `nixpkgs` exposes packages at the
44package level. If packages mutually depend on each other through tests
45and libraries, this leads to cyclic dependencies that nix can't resolve. By
46exposing the components to nix as separate derivations this will only
47occur if you have mutually dependent components.
49## Build times
51The Haskell builder in nixpkgs builds a package sequentially, first the
52library then the executables and finally the tests. It then executes
53the tests before the package is considered done. The upshot of this
54is that packages are only considered done if the test-suites
55passed. The downside is that if you have to compile multiple packages
56the likelihood of them failing is low, you have unnecessarily
57serialized your build. In a more aggressive setting libraries could
58start building as early as their dependent libraries are built. Of
59course they will have to be invalidated later should the test-suites
60of their dependencies fail, but this way we can make use of parallel
61building. In an ideal scenario this will reduce build times close to
62the optimum.
64## More logic in nix
66The `cabal2nix` tool has a resolver that resolves system dependencies
67and licenses to values in `nixpkgs`. This logic ends up being a simple
68dictionary lookup and therefore can be a simple nix expression. This also
69offloads some of the work the cabal to nix translation tool needs to
70do into nix, and as such if changes are necessary (or needed to be
71performed ad hoc) there is no need to rebuild the conversion tool and
72subsequently mark every derived expression as out of date.
74## Decoupling
76Finally, by treating Haskell.nix and nixpkgs as separate entities we
77can decouple the Haskell packages and infrastructure from the nixpkgs
78package set, and rely on it to provide us with system packages while
79staying up to date with Haskell packages from hackage while retaining
80a stable (or known to be good) nixpkgs revision.