···
1
-
<chapter xmlns="http://docbook.org/ns/docbook"
2
-
xmlns:xlink="http://www.w3.org/1999/xlink"
3
-
xml:id="users-guide-to-the-haskell-infrastructure">
5
-
<title>User's Guide to the Haskell Infrastructure</title>
7
-
<section xml:id="how-to-install-haskell-packages">
8
-
<title>How to install Haskell packages</title>
10
-
Nixpkgs distributes build instructions for all Haskell packages
12
-
<link xlink:href="http://hackage.haskell.org/">Hackage</link>, but
13
-
strangely enough normal Nix package lookups don't seem to discover
14
-
any of them, except for the default version of ghc, cabal-install, and stack:
18
-
error: selector ‘alex’ matches no derivations
23
-
The Haskell package set is not registered in the top-level namespace
24
-
because it is <emphasis>huge</emphasis>. If all Haskell packages
25
-
were visible to these commands, then name-based search/install
26
-
operations would be much slower than they are now. We avoided that
27
-
by keeping all Haskell-related packages in a separate attribute set
28
-
called <literal>haskellPackages</literal>, which the following
32
-
$ nix-env -f "<nixpkgs>" -qaP -A haskellPackages
33
-
haskellPackages.a50 a50-0.5
34
-
haskellPackages.abacate haskell-abacate-0.0.0.0
35
-
haskellPackages.abcBridge haskell-abcBridge-0.12
36
-
haskellPackages.afv afv-0.1.1
37
-
haskellPackages.alex alex-3.1.4
38
-
haskellPackages.Allure Allure-0.4.101.1
39
-
haskellPackages.alms alms-0.6.7
40
-
[... some 8000 entries omitted ...]
43
-
To install any of those packages into your profile, refer to them by
44
-
their attribute path (first column):
47
-
$ nix-env -f "<nixpkgs>" -iA haskellPackages.Allure ...
50
-
The attribute path of any Haskell packages corresponds to the name
51
-
of that particular package on Hackage: the package
52
-
<literal>cabal-install</literal> has the attribute
53
-
<literal>haskellPackages.cabal-install</literal>, and so on.
54
-
(Actually, this convention causes trouble with packages like
55
-
<literal>3dmodels</literal> and <literal>4Blocks</literal>, because
56
-
these names are invalid identifiers in the Nix language. The issue
57
-
of how to deal with these rare corner cases is currently
61
-
Haskell packages who's Nix name (second column) begins with a
62
-
<literal>haskell-</literal> prefix are packages that provide a
63
-
library whereas packages without that prefix provide just
64
-
executables. Libraries may provide executables too, though: the
65
-
package <literal>haskell-pandoc</literal>, for example, installs
66
-
both a library and an application. You can install and use Haskell
67
-
executables just like any other program in Nixpkgs, but using
68
-
Haskell libraries for development is a bit trickier and we'll
69
-
address that subject in great detail in section
70
-
<link linkend="how-to-create-a-development-environment">How to
71
-
create a development environment</link>.
74
-
Attribute paths are deterministic inside of Nixpkgs, but the path
75
-
necessary to reach Nixpkgs varies from system to system. We dodged
76
-
that problem by giving <literal>nix-env</literal> an explicit
77
-
<literal>-f "<nixpkgs>"</literal> parameter, but if
78
-
you call <literal>nix-env</literal> without that flag, then chances
79
-
are the invocation fails:
82
-
$ nix-env -iA haskellPackages.cabal-install
83
-
error: attribute ‘haskellPackages’ in selection path
84
-
‘haskellPackages.cabal-install’ not found
87
-
On NixOS, for example, Nixpkgs does <emphasis>not</emphasis> exist
88
-
in the top-level namespace by default. To figure out the proper
89
-
attribute path, it's easiest to query for the path of a well-known
90
-
Nixpkgs package, i.e.:
93
-
$ nix-env -qaP coreutils
94
-
nixos.coreutils coreutils-8.23
97
-
If your system responds like that (most NixOS installations will),
98
-
then the attribute path to <literal>haskellPackages</literal> is
99
-
<literal>nixos.haskellPackages</literal>. Thus, if you want to
100
-
use <literal>nix-env</literal> without giving an explicit
101
-
<literal>-f</literal> flag, then that's the way to do it:
104
-
$ nix-env -qaP -A nixos.haskellPackages
105
-
$ nix-env -iA nixos.haskellPackages.cabal-install
108
-
Our current default compiler is GHC 7.10.x and the
109
-
<literal>haskellPackages</literal> set contains packages built with
110
-
that particular version. Nixpkgs contains the latest major release
111
-
of every GHC since 6.10.4, however, and there is a whole family of
112
-
package sets available that defines Hackage packages built with each
113
-
of those compilers, too:
116
-
$ nix-env -f "<nixpkgs>" -qaP -A haskell.packages.ghc6123
117
-
$ nix-env -f "<nixpkgs>" -qaP -A haskell.packages.ghc763
120
-
The name <literal>haskellPackages</literal> is really just a synonym
121
-
for <literal>haskell.packages.ghc7102</literal>, because we prefer
122
-
that package set internally and recommend it to our users as their
123
-
default choice, but ultimately you are free to compile your Haskell
124
-
packages with any GHC version you please. The following command
125
-
displays the complete list of available compilers:
128
-
$ nix-env -f "<nixpkgs>" -qaP -A haskell.compiler
129
-
haskell.compiler.ghc6104 ghc-6.10.4
130
-
haskell.compiler.ghc6123 ghc-6.12.3
131
-
haskell.compiler.ghc704 ghc-7.0.4
132
-
haskell.compiler.ghc722 ghc-7.2.2
133
-
haskell.compiler.ghc742 ghc-7.4.2
134
-
haskell.compiler.ghc763 ghc-7.6.3
135
-
haskell.compiler.ghc784 ghc-7.8.4
136
-
haskell.compiler.ghc7102 ghc-7.10.2
137
-
haskell.compiler.ghcHEAD ghc-7.11.20150402
138
-
haskell.compiler.ghcNokinds ghc-nokinds-7.11.20150704
139
-
haskell.compiler.ghcjs ghcjs-0.1.0
140
-
haskell.compiler.jhc jhc-0.8.2
141
-
haskell.compiler.uhc uhc-1.1.9.0
144
-
We have no package sets for <literal>jhc</literal> or
145
-
<literal>uhc</literal> yet, unfortunately, but for every version of
146
-
GHC listed above, there exists a package set based on that compiler.
147
-
Also, the attributes <literal>haskell.compiler.ghcXYC</literal> and
148
-
<literal>haskell.packages.ghcXYC.ghc</literal> are synonymous for
149
-
the sake of convenience.
152
-
<section xml:id="how-to-create-a-development-environment">
153
-
<title>How to create a development environment</title>
154
-
<section xml:id="how-to-install-a-compiler">
155
-
<title>How to install a compiler</title>
157
-
A simple development environment consists of a Haskell compiler
158
-
and the tool <literal>cabal-install</literal>, and we saw in
159
-
section <link linkend="how-to-install-haskell-packages">How to
160
-
install Haskell packages</link> how you can install those programs
161
-
into your user profile:
164
-
$ nix-env -f "<nixpkgs>" -iA haskellPackages.ghc haskellPackages.cabal-install
167
-
Instead of the default package set
168
-
<literal>haskellPackages</literal>, you can also use the more
169
-
precise name <literal>haskell.compiler.ghc7102</literal>, which
170
-
has the advantage that it refers to the same GHC version
171
-
regardless of what Nixpkgs considers "default" at any
175
-
Once you've made those tools available in
176
-
<literal>$PATH</literal>, it's possible to build Hackage packages
177
-
the same way people without access to Nix do it all the time:
180
-
$ cabal get lens-4.11 && cd lens-4.11
181
-
$ cabal install -j --dependencies-only
186
-
If you enjoy working with Cabal sandboxes, then that's entirely
187
-
possible too: just execute the command
190
-
$ cabal sandbox init
193
-
before installing the required dependencies.
196
-
The <literal>nix-shell</literal> utility makes it easy to switch
197
-
to a different compiler version; just enter the Nix shell
198
-
environment with the command
201
-
$ nix-shell -p haskell.compiler.ghc784
204
-
to bring GHC 7.8.4 into <literal>$PATH</literal>. Re-running
205
-
<literal>cabal configure</literal> switches your build to use that
206
-
compiler instead. If you're working on a project that doesn't
207
-
depend on any additional system libraries outside of GHC, then
208
-
it's sufficient even to run the <literal>cabal configure</literal>
209
-
command inside of the shell:
212
-
$ nix-shell -p haskell.compiler.ghc784 --command "cabal configure"
215
-
Afterwards, all other commands like <literal>cabal build</literal>
216
-
work just fine in any shell environment, because the configure
217
-
phase recorded the absolute paths to all required tools like GHC
218
-
in its build configuration inside of the <literal>dist/</literal>
219
-
directory. Please note, however, that
220
-
<literal>nix-collect-garbage</literal> can break such an
221
-
environment because the Nix store paths created by
222
-
<literal>nix-shell</literal> aren't "alive" anymore once
223
-
<literal>nix-shell</literal> has terminated. If you find that your
224
-
Haskell builds no longer work after garbage collection, then
225
-
you'll have to re-run <literal>cabal configure</literal> inside of
226
-
a new <literal>nix-shell</literal> environment.
229
-
<section xml:id="how-to-install-a-compiler-with-libraries">
230
-
<title>How to install a compiler with libraries</title>
232
-
GHC expects to find all installed libraries inside of its own
233
-
<literal>lib</literal> directory. This approach works fine on
234
-
traditional Unix systems, but it doesn't work for Nix, because
235
-
GHC's store path is immutable once it's built. We cannot install
236
-
additional libraries into that location. As a consequence, our
237
-
copies of GHC don't know any packages except their own core
238
-
libraries, like <literal>base</literal>,
239
-
<literal>containers</literal>, <literal>Cabal</literal>, etc.
242
-
We can register additional libraries to GHC, however, using a
243
-
special build function called <literal>ghcWithPackages</literal>.
244
-
That function expects one argument: a function that maps from an
245
-
attribute set of Haskell packages to a list of packages, which
246
-
determines the libraries known to that particular version of GHC.
247
-
For example, the Nix expression
248
-
<literal>ghcWithPackages (pkgs: [pkgs.mtl])</literal> generates a
249
-
copy of GHC that has the <literal>mtl</literal> library registered
250
-
in addition to its normal core packages:
253
-
$ nix-shell -p "haskellPackages.ghcWithPackages (pkgs: [pkgs.mtl])"
255
-
[nix-shell:~]$ ghc-pkg list mtl
256
-
/nix/store/zy79...-ghc-7.10.2/lib/ghc-7.10.2/package.conf.d:
260
-
This function allows users to define their own development
261
-
environment by means of an override. After adding the following
262
-
snippet to <literal>~/.nixpkgs/config.nix</literal>,
266
-
packageOverrides = super: let self = super.pkgs; in
268
-
myHaskellEnv = self.haskell.packages.ghc7102.ghcWithPackages
269
-
(haskellPackages: with haskellPackages; [
271
-
arrows async cgi criterion
273
-
cabal-install haskintex
279
-
it's possible to install that compiler with
280
-
<literal>nix-env -f "<nixpkgs>" -iA myHaskellEnv</literal>.
281
-
If you'd like to switch that development environment to a
282
-
different version of GHC, just replace the
283
-
<literal>ghc7102</literal> bit in the previous definition with the
284
-
appropriate name. Of course, it's also possible to define any
285
-
number of these development environments! (You can't install two
286
-
of them into the same profile at the same time, though, because
287
-
that would result in file conflicts.)
290
-
The generated <literal>ghc</literal> program is a wrapper script
291
-
that re-directs the real GHC executable to use a new
292
-
<literal>lib</literal> directory --- one that we specifically
293
-
constructed to contain all those packages the user requested:
296
-
$ cat $(type -p ghc)
297
-
#! /nix/store/xlxj...-bash-4.3-p33/bin/bash -e
298
-
export NIX_GHC=/nix/store/19sm...-ghc-7.10.2/bin/ghc
299
-
export NIX_GHCPKG=/nix/store/19sm...-ghc-7.10.2/bin/ghc-pkg
300
-
export NIX_GHC_DOCDIR=/nix/store/19sm...-ghc-7.10.2/share/doc/ghc/html
301
-
export NIX_GHC_LIBDIR=/nix/store/19sm...-ghc-7.10.2/lib/ghc-7.10.2
302
-
exec /nix/store/j50p...-ghc-7.10.2/bin/ghc "-B$NIX_GHC_LIBDIR" "$@"
305
-
The variables <literal>$NIX_GHC</literal>,
306
-
<literal>$NIX_GHCPKG</literal>, etc. point to the
307
-
<emphasis>new</emphasis> store path
308
-
<literal>ghcWithPackages</literal> constructed specifically for
309
-
this environment. The last line of the wrapper script then
310
-
executes the real <literal>ghc</literal>, but passes the path to
311
-
the new <literal>lib</literal> directory using GHC's
312
-
<literal>-B</literal> flag.
315
-
The purpose of those environment variables is to work around an
316
-
impurity in the popular
317
-
<link xlink:href="http://hackage.haskell.org/package/ghc-paths">ghc-paths</link>
318
-
library. That library promises to give its users access to GHC's
319
-
installation paths. Only, the library can't possible know that
320
-
path when it's compiled, because the path GHC considers its own is
321
-
determined only much later, when the user configures it through
322
-
<literal>ghcWithPackages</literal>. So we
323
-
<link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/haskell-modules/ghc-paths-nix.patch">patched
324
-
ghc-paths</link> to return the paths found in those environment
325
-
variables at run-time rather than trying to guess them at
329
-
To make sure that mechanism works properly all the time, we
330
-
recommend that you set those variables to meaningful values in
331
-
your shell environment, too, i.e. by adding the following code to
332
-
your <literal>~/.bashrc</literal>:
335
-
if type >/dev/null 2>&1 -p ghc; then
336
-
eval "$(egrep ^export "$(type -p ghc)")"
340
-
If you are certain that you'll use only one GHC environment which
341
-
is located in your user profile, then you can use the following
342
-
code, too, which has the advantage that it doesn't contain any
343
-
paths from the Nix store, i.e. those settings always remain valid
344
-
even if a <literal>nix-env -u</literal> operation updates the GHC
345
-
environment in your profile:
348
-
if [ -e ~/.nix-profile/bin/ghc ]; then
349
-
export NIX_GHC="$HOME/.nix-profile/bin/ghc"
350
-
export NIX_GHCPKG="$HOME/.nix-profile/bin/ghc-pkg"
351
-
export NIX_GHC_DOCDIR="$HOME/.nix-profile/share/doc/ghc/html"
352
-
export NIX_GHC_LIBDIR="$HOME/.nix-profile/lib/ghc-$($NIX_GHC --numeric-version)"
356
-
<section xml:id="how-to-install-a-compiler-with-indexes">
357
-
<title>How to install a compiler with libraries, hoogle and documentation indexes</title>
359
-
If you plan to use your environment for interactive programming,
360
-
not just compiling random Haskell code, you might want to
361
-
replace <literal>ghcWithPackages</literal> in all the listings
362
-
above with <literal>ghcWithHoogle</literal>.
365
-
This environment generator not only produces an environment with
366
-
GHC and all the specified libraries, but also generates a
367
-
<literal>hoogle</literal> and <literal>haddock</literal> indexes
368
-
for all the packages, and provides a wrapper script around
369
-
<literal>hoogle</literal> binary that uses all those things. A
370
-
precise name for this thing would be
371
-
"<literal>ghcWithPackagesAndHoogleAndDocumentationIndexes</literal>",
372
-
which is, regrettably, too long and scary.
375
-
For example, installing the following environment
379
-
packageOverrides = super: let self = super.pkgs; in
381
-
myHaskellEnv = self.haskellPackages.ghcWithHoogle
382
-
(haskellPackages: with haskellPackages; [
384
-
arrows async cgi criterion
386
-
cabal-install haskintex
392
-
allows one to browse module documentation index <link
393
-
xlink:href="https://downloads.haskell.org/~ghc/latest/docs/html/libraries/index.html">not
394
-
too dissimilar to this</link> for all the specified packages and
395
-
their dependencies by directing a browser of choice to
396
-
<literal>~/.nix-profiles/share/doc/hoogle/index.html</literal>
398
-
<literal>/run/current-system/sw/share/doc/hoogle/index.html</literal>
399
-
in case you put it in
400
-
<literal>environment.systemPackages</literal> in NixOS).
403
-
After you've marveled enough at that try adding the following to
404
-
your <literal>~/.ghc/ghci.conf</literal>
407
-
:def hoogle \s -> return $ ":! hoogle search -cl --count=15 \"" ++ s ++ "\""
408
-
:def doc \s -> return $ ":! hoogle search -cl --info \"" ++ s ++ "\""
411
-
and test it by typing into <literal>ghci</literal>:
418
-
Be sure to note the links to <literal>haddock</literal> files in
419
-
the output. With any modern and properly configured terminal
420
-
emulator you can just click those links to navigate there.
423
-
Finally, you can run
426
-
hoogle server -p 8080
429
-
and navigate to <link xlink:href="http://localhost:8080/"/> for
430
-
your own local <link
431
-
xlink:href="https://www.haskell.org/hoogle/">Hoogle</link>.
432
-
Note, however, that Firefox and possibly other browsers disallow
433
-
navigation from <literal>http:</literal> to
434
-
<literal>file:</literal> URIs for security reasons, which might
435
-
be quite an inconvenience. See <link
436
-
xlink:href="http://kb.mozillazine.org/Links_to_local_pages_do_not_work">this
437
-
page</link> for workarounds.
440
-
<section xml:id="how-to-create-ad-hoc-environments-for-nix-shell">
441
-
<title>How to create ad hoc environments for
442
-
<literal>nix-shell</literal></title>
444
-
The easiest way to create an ad hoc development environment is to
445
-
run <literal>nix-shell</literal> with the appropriate GHC
446
-
environment given on the command-line:
449
-
nix-shell -p "haskellPackages.ghcWithPackages (pkgs: with pkgs; [mtl pandoc])"
452
-
For more sophisticated use-cases, however, it's more convenient to
453
-
save the desired configuration in a file called
454
-
<literal>shell.nix</literal> that looks like this:
457
-
{ nixpkgs ? import <nixpkgs> {}, compiler ? "ghc7102" }:
459
-
inherit (nixpkgs) pkgs;
460
-
ghc = pkgs.haskell.packages.${compiler}.ghcWithPackages (ps: with ps; [
464
-
pkgs.stdenv.mkDerivation {
465
-
name = "my-haskell-env-0";
466
-
buildInputs = [ ghc ];
467
-
shellHook = "eval $(egrep ^export ${ghc}/bin/ghc)";
471
-
Now run <literal>nix-shell</literal> --- or even
472
-
<literal>nix-shell --pure</literal> --- to enter a shell
473
-
environment that has the appropriate compiler in
474
-
<literal>$PATH</literal>. If you use <literal>--pure</literal>,
475
-
then add all other packages that your development environment
476
-
needs into the <literal>buildInputs</literal> attribute. If you'd
477
-
like to switch to a different compiler version, then pass an
478
-
appropriate <literal>compiler</literal> argument to the
480
-
<literal>nix-shell --argstr compiler ghc784</literal>.
483
-
If you need such an environment because you'd like to compile a
484
-
Hackage package outside of Nix --- i.e. because you're hacking on
485
-
the latest version from Git ---, then the package set provides
486
-
suitable nix-shell environments for you already! Every Haskell
487
-
package has an <literal>env</literal> attribute that provides a
488
-
shell environment suitable for compiling that particular package.
489
-
If you'd like to hack the <literal>lens</literal> library, for
490
-
example, then you just have to check out the source code and enter
491
-
the appropriate environment:
494
-
$ cabal get lens-4.11 && cd lens-4.11
495
-
Downloading lens-4.11...
496
-
Unpacking to lens-4.11/
498
-
$ nix-shell "<nixpkgs>" -A haskellPackages.lens.env
499
-
[nix-shell:/tmp/lens-4.11]$
502
-
At point, you can run <literal>cabal configure</literal>,
503
-
<literal>cabal build</literal>, and all the other development
504
-
commands. Note that you need <literal>cabal-install</literal>
505
-
installed in your <literal>$PATH</literal> already to use it here
506
-
--- the <literal>nix-shell</literal> environment does not provide
511
-
<section xml:id="how-to-create-nix-builds-for-your-own-private-haskell-packages">
512
-
<title>How to create Nix builds for your own private Haskell
515
-
If your own Haskell packages have build instructions for Cabal, then
516
-
you can convert those automatically into build instructions for Nix
517
-
using the <literal>cabal2nix</literal> utility, which you can
518
-
install into your profile by running
519
-
<literal>nix-env -i cabal2nix</literal>.
521
-
<section xml:id="how-to-build-a-stand-alone-project">
522
-
<title>How to build a stand-alone project</title>
524
-
For example, let's assume that you're working on a private project
525
-
called <literal>foo</literal>. To generate a Nix build expression
526
-
for it, change into the project's top-level directory and run the
530
-
$ cabal2nix . >foo.nix
533
-
Then write the following snippet into a file called
534
-
<literal>default.nix</literal>:
537
-
{ nixpkgs ? import <nixpkgs> {}, compiler ? "ghc7102" }:
538
-
nixpkgs.pkgs.haskell.packages.${compiler}.callPackage ./foo.nix { }
541
-
Finally, store the following code in a file called
542
-
<literal>shell.nix</literal>:
545
-
{ nixpkgs ? import <nixpkgs> {}, compiler ? "ghc7102" }:
546
-
(import ./default.nix { inherit nixpkgs compiler; }).env
549
-
At this point, you can run <literal>nix-build</literal> to have
550
-
Nix compile your project and install it into a Nix store path. The
551
-
local directory will contain a symlink called
552
-
<literal>result</literal> after <literal>nix-build</literal>
553
-
returns that points into that location. Of course, passing the
554
-
flag <literal>--argstr compiler ghc763</literal> allows switching
555
-
the build to any version of GHC currently supported.
558
-
Furthermore, you can call <literal>nix-shell</literal> to enter an
559
-
interactive development environment in which you can use
560
-
<literal>cabal configure</literal> and
561
-
<literal>cabal build</literal> to develop your code. That
562
-
environment will automatically contain a proper GHC derivation
563
-
with all the required libraries registered as well as all the
564
-
system-level libraries your package might need.
567
-
If your package does not depend on any system-level libraries,
568
-
then it's sufficient to run
571
-
$ nix-shell --command "cabal configure"
574
-
once to set up your build. <literal>cabal-install</literal>
575
-
determines the absolute paths to all resources required for the
576
-
build and writes them into a config file in the
577
-
<literal>dist/</literal> directory. Once that's done, you can run
578
-
<literal>cabal build</literal> and any other command for that
579
-
project even outside of the <literal>nix-shell</literal>
580
-
environment. This feature is particularly nice for those of us who
581
-
like to edit their code with an IDE, like Emacs'
582
-
<literal>haskell-mode</literal>, because it's not necessary to
583
-
start Emacs inside of nix-shell just to make it find out the
584
-
necessary settings for building the project;
585
-
<literal>cabal-install</literal> has already done that for us.
588
-
If you want to do some quick-and-dirty hacking and don't want to
589
-
bother setting up a <literal>default.nix</literal> and
590
-
<literal>shell.nix</literal> file manually, then you can use the
591
-
<literal>--shell</literal> flag offered by
592
-
<literal>cabal2nix</literal> to have it generate a stand-alone
593
-
<literal>nix-shell</literal> environment for you. With that
597
-
$ cabal2nix --shell . >shell.nix
598
-
$ nix-shell --command "cabal configure"
601
-
is usually enough to set up a build environment for any given
602
-
Haskell package. You can even use that generated file to run
603
-
<literal>nix-build</literal>, too:
606
-
$ nix-build shell.nix
609
-
<section xml:id="how-to-build-projects-that-depend-on-each-other">
610
-
<title>How to build projects that depend on each other</title>
612
-
If you have multiple private Haskell packages that depend on each
613
-
other, then you'll have to register those packages in the Nixpkgs
614
-
set to make them visible for the dependency resolution performed
615
-
by <literal>callPackage</literal>. First of all, change into each
616
-
of your projects top-level directories and generate a
617
-
<literal>default.nix</literal> file with
618
-
<literal>cabal2nix</literal>:
621
-
$ cd ~/src/foo && cabal2nix . >default.nix
622
-
$ cd ~/src/bar && cabal2nix . >default.nix
625
-
Then edit your <literal>~/.nixpkgs/config.nix</literal> file to
626
-
register those builds in the default Haskell package set:
630
-
packageOverrides = super: let self = super.pkgs; in
632
-
haskellPackages = super.haskellPackages.override {
633
-
overrides = self: super: {
634
-
foo = self.callPackage ../src/foo {};
635
-
bar = self.callPackage ../src/bar {};
642
-
Once that's accomplished,
643
-
<literal>nix-env -f "<nixpkgs>" -qA haskellPackages</literal>
644
-
will show your packages like any other package from Hackage, and
648
-
$ nix-build "<nixpkgs>" -A haskellPackages.foo
651
-
or enter an interactive shell environment suitable for building
655
-
$ nix-shell "<nixpkgs>" -A haskellPackages.bar.env
659
-
<section xml:id="miscellaneous-topics">
660
-
<title>Miscellaneous Topics</title>
661
-
<section xml:id="how-to-build-with-profiling-enabled">
662
-
<title>How to build with profiling enabled</title>
664
-
Every Haskell package set takes a function called
665
-
<literal>overrides</literal> that you can use to manipulate the
666
-
package as much as you please. One useful application of this
667
-
feature is to replace the default <literal>mkDerivation</literal>
668
-
function with one that enables library profiling for all packages.
669
-
To accomplish that, add configure the following snippet in your
670
-
<literal>~/.nixpkgs/config.nix</literal> file:
674
-
packageOverrides = super: let self = super.pkgs; in
676
-
profiledHaskellPackages = self.haskellPackages.override {
677
-
overrides = self: super: {
678
-
mkDerivation = args: super.mkDerivation (args // {
679
-
enableLibraryProfiling = true;
687
-
Then, replace instances of <literal>haskellPackages</literal> in the
688
-
<literal>cabal2nix</literal>-generated <literal>default.nix</literal>
689
-
or <literal>shell.nix</literal> files with
690
-
<literal>profiledHaskellPackages</literal>.
693
-
<section xml:id="how-to-override-package-versions-in-a-compiler-specific-package-set">
694
-
<title>How to override package versions in a compiler-specific
695
-
package set</title>
697
-
Nixpkgs provides the latest version of
698
-
<link xlink:href="http://hackage.haskell.org/package/ghc-events"><literal>ghc-events</literal></link>,
699
-
which is 0.4.4.0 at the time of this writing. This is fine for
700
-
users of GHC 7.10.x, but GHC 7.8.4 cannot compile that binary.
701
-
Now, one way to solve that problem is to register an older version
702
-
of <literal>ghc-events</literal> in the 7.8.x-specific package
703
-
set. The first step is to generate Nix build instructions with
704
-
<literal>cabal2nix</literal>:
707
-
$ cabal2nix cabal://ghc-events-0.4.3.0 >~/.nixpkgs/ghc-events-0.4.3.0.nix
710
-
Then add the override in <literal>~/.nixpkgs/config.nix</literal>:
714
-
packageOverrides = super: let self = super.pkgs; in
716
-
haskell = super.haskell // {
717
-
packages = super.haskell.packages // {
718
-
ghc784 = super.haskell.packages.ghc784.override {
719
-
overrides = self: super: {
720
-
ghc-events = self.callPackage ./ghc-events-0.4.3.0.nix {};
729
-
This code is a little crazy, no doubt, but it's necessary because
730
-
the intuitive version
733
-
haskell.packages.ghc784 = super.haskell.packages.ghc784.override {
734
-
overrides = self: super: {
735
-
ghc-events = self.callPackage ./ghc-events-0.4.3.0.nix {};
740
-
doesn't do what we want it to: that code replaces the
741
-
<literal>haskell</literal> package set in Nixpkgs with one that
742
-
contains only one entry,<literal>packages</literal>, which
743
-
contains only one entry <literal>ghc784</literal>. This override
744
-
loses the <literal>haskell.compiler</literal> set, and it loses
745
-
the <literal>haskell.packages.ghcXYZ</literal> sets for all
746
-
compilers but GHC 7.8.4. To avoid that problem, we have to perform
747
-
the convoluted little dance from above, iterating over each step
751
-
Once it's accomplished, however, we can install a variant of
752
-
<literal>ghc-events</literal> that's compiled with GHC 7.8.4:
755
-
nix-env -f "<nixpkgs>" -iA haskell.packages.ghc784.ghc-events
758
-
Unfortunately, it turns out that this build fails again while
759
-
executing the test suite! Apparently, the release archive on
760
-
Hackage is missing some data files that the test suite requires,
761
-
so we cannot run it. We accomplish that by re-generating the Nix
762
-
expression with the <literal>--no-check</literal> flag:
765
-
$ cabal2nix --no-check cabal://ghc-events-0.4.3.0 >~/.nixpkgs/ghc-events-0.4.3.0.nix
768
-
Now the builds succeeds.
771
-
Of course, in the concrete example of
772
-
<literal>ghc-events</literal> this whole exercise is not an ideal
773
-
solution, because <literal>ghc-events</literal> can analyze the
774
-
output emitted by any version of GHC later than 6.12 regardless of
775
-
the compiler version that was used to build the `ghc-events'
776
-
executable, so strictly speaking there's no reason to prefer one
777
-
built with GHC 7.8.x in the first place. However, for users who
778
-
cannot use GHC 7.10.x at all for some reason, the approach of
779
-
downgrading to an older version might be useful.
782
-
<section xml:id="how-to-recover-from-ghcs-infamous-non-deterministic-library-id-bug">
783
-
<title>How to recover from GHC's infamous non-deterministic library
786
-
GHC and distributed build farms don't get along well:
789
-
https://ghc.haskell.org/trac/ghc/ticket/4012
792
-
When you see an error like this one
795
-
package foo-0.7.1.0 is broken due to missing package
796
-
text-1.2.0.4-98506efb1b9ada233bb5c2b2db516d91
799
-
then you have to download and re-install <literal>foo</literal>
800
-
and all its dependents from scratch:
803
-
# nix-store -q --referrers /nix/store/*-haskell-text-1.2.0.4 \
804
-
| xargs -L 1 nix-store --repair-path --option binary-caches http://hydra.nixos.org
807
-
If you're using additional Hydra servers other than
808
-
<literal>hydra.nixos.org</literal>, then it might be necessary to
809
-
purge the local caches that store data from those machines to
810
-
disable these binary channels for the duration of the previous
811
-
command, i.e. by running:
814
-
rm /nix/var/nix/binary-cache-v3.sqlite
815
-
rm /nix/var/nix/manifests/*
816
-
rm /nix/var/nix/channel-cache/*
819
-
<section xml:id="builds-on-darwin-fail-with-math.h-not-found">
820
-
<title>Builds on Darwin fail with <literal>math.h</literal> not
823
-
Users of GHC on Darwin have occasionally reported that builds
824
-
fail, because the compiler complains about a missing include file:
827
-
fatal error: 'math.h' file not found
830
-
The issue has been discussed at length in
831
-
<link xlink:href="https://github.com/NixOS/nixpkgs/issues/6390">ticket
832
-
6390</link>, and so far no good solution has been proposed. As a
833
-
work-around, users who run into this problem can configure the
834
-
environment variables
837
-
export NIX_CFLAGS_COMPILE="-idirafter /usr/include"
838
-
export NIX_CFLAGS_LINK="-L/usr/lib"
841
-
in their <literal>~/.bashrc</literal> file to avoid the compiler
847
-
<section xml:id="other-resources">
848
-
<title>Other resources</title>
853
-
<link xlink:href="https://www.youtube.com/watch?v=BsBhi_r-OeE">Nix
854
-
Loves Haskell</link> provides an introduction into Haskell NG
855
-
aimed at beginners. The slides are available at
856
-
http://cryp.to/nixos-meetup-3-slides.pdf and also -- in a form
857
-
ready for cut & paste -- at
858
-
https://github.com/NixOS/cabal2nix/blob/master/doc/nixos-meetup-3-slides.md.
863
-
Another Youtube video is
864
-
<link xlink:href="https://www.youtube.com/watch?v=mQd3s57n_2Y">Escaping
865
-
Cabal Hell with Nix</link>, which discusses the subject of
866
-
Haskell development with Nix but also provides a basic
867
-
introduction to Nix as well, i.e. it's suitable for viewers with
868
-
almost no prior Nix experience.
873
-
Oliver Charles wrote a very nice
874
-
<link xlink:href="http://wiki.ocharles.org.uk/Nix">Tutorial how to
875
-
develop Haskell packages with Nix</link>.
880
-
The <emphasis>Journey into the Haskell NG
881
-
infrastructure</emphasis> series of postings describe the new
882
-
Haskell infrastructure in great detail:
887
-
<link xlink:href="http://lists.science.uu.nl/pipermail/nix-dev/2015-January/015591.html">Part
888
-
1</link> explains the differences between the old and the
889
-
new code and gives instructions how to migrate to the new
895
-
<link xlink:href="http://lists.science.uu.nl/pipermail/nix-dev/2015-January/015608.html">Part
896
-
2</link> looks in-depth at how to tweak and configure your
897
-
setup by means of overrides.
902
-
<link xlink:href="http://lists.science.uu.nl/pipermail/nix-dev/2015-April/016912.html">Part
903
-
3</link> describes the infrastructure that keeps the
904
-
Haskell package set in Nixpkgs up-to-date.
pyrox.dev