36 lines
1.0 KiB
Markdown
36 lines
1.0 KiB
Markdown
|
---
|
||
|
|
title: Nix and Haskell
|
||
|
|
date: 2018-09-20
|
||
|
|
---
|
||
|
|
|
||
|
|
The simplest way you can use haskell and nix together is by calling
|
||
|
|
`callCabal2nix` on the cabal file and using the resulting artifacts.
|
||
|
|
|
||
|
|
I usually create two files `release.nix` and `default.nix`. At least when
|
||
|
|
developing, I avoid using the `cabal2nix` tool and instead let nix handle
|
||
|
|
calling it for me. If I ever published an actual package, I would probably
|
||
|
|
provide the autogenerated `default.nix` and nothing else.
|
||
|
|
|
||
|
|
**Build instructions** are managed by `default.nix`. At its simplest it's just
|
||
|
|
a call to `callCabal2nix`, but might contain for example some extra cabal flags
|
||
|
|
or adding patches.
|
||
|
|
|
||
|
|
```nix
|
||
|
|
# default.nix
|
||
|
|
{ haskellPackages }:
|
||
|
|
|
||
|
|
haskellPackages.callCabal2nix "foo" ./. {}
|
||
|
|
```
|
||
|
|
|
||
|
|
**Pinning** of haskell packages and system libraries are managed by this file.
|
||
|
|
Nixpkgs requires a bootstrap `<nixpkgs>` in scope so that we can pin to a
|
||
|
|
specific commit hash.
|
||
|
|
|
||
|
|
```nix
|
||
|
|
# release.nix
|
||
|
|
{ pkgs ? import <nixpkgs> {} }:
|
||
|
|
|
||
|
|
# No pinning yet
|
||
|
|
pkgs.callPackage ./default.nix {}
|
||
|
|
```
|