Remove post
This commit is contained in:
parent
e2a213b08d
commit
7557f5041c
@ -1,35 +0,0 @@
|
||||
---
|
||||
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 {}
|
||||
```
|
Loading…
Reference in New Issue
Block a user