Verified Commit b56b4264 authored by doshitan's avatar doshitan
Browse files

Moar nix page content

parent 57698b37
......@@ -244,6 +244,9 @@ with you editor. See the [section on a persistent and cached
for nix with direnv.
If you're feeling adventurous, look into <>
instead of using the `nix-shell` direnv stuff directly.
# Language-specific things
......@@ -285,7 +288,9 @@ pkgs.haskellPackages.developPackage {
This automatically calls `cabal2nix`, makes it easy to specify overrides and such.
This automatically calls `cabal2nix`, makes it easy to specify overrides, and
will drop you into a development shell when `nix-shell` is used (no need for a
separate `shell.nix`).
If you want to fix a compiler version, say the default is too new for you:
......@@ -366,14 +371,44 @@ pkgs.haskell.packages."${ghcVersion}".developPackage {
# package set
some-package = pkgs.haskell.lib.appendPatch oldHaskellPkgs.some-package ./fix-some-package.patch;
# this is a spot you can modify the derivation for the package itself,
# usually will be applying one haskell lib function like in `overrides`
modifier = pkgs.haskell.lib.buildStrictly;
If you want to add some development tools to the `nix-shell` environment, one
way you could do it is with a `shell.nix` containing:
```{.nix caption="shell.nix"}
{ pkgs ? import <nixpkgs> {} }:
package = import ./default.nix { inherit pkgs; };
package.overrideAttrs (oldAttrs: {
buildInputs = oldAttrs.buildInputs ++ [
# ...
Though keeping the right compiler version/package set in sync between the dev
tools and the package environment from `developPackage` could be challenging
since the package set from `developPackage` isn't exposed. I'm not sure as I
don't use this setup.
For this and other reasons I generally recommend the next development setup, but
`developPackage` is quick when you need it.
## Improved setup
While `haskellPackages.developPackage` is pretty easy, for any non-trivial
project, you are probably going to want a little more control, particularly over
the shell environment.
While `haskellPackages.developPackage` is pretty easy, for projects with more
than one package, or if you just want more flexibility, or explicitness, you can
break apart what `developPackage` is doing.
In your `default.nix`, extend the Haskell package set to include the project packages:
......@@ -561,6 +596,8 @@ experiment with what else is possible.
- <>
- <>
- <>
- <>
# Learning Nix
......@@ -653,6 +690,7 @@ would do something in Ubuntu and the equivalent command on NixOS.
It also has a bunch of short little snippets about how to do various things,
cross-compile a package, and other similar tasks.
# Get source hash
So anytime something is fetched in a nix expression, we want the hash of the
......@@ -693,6 +731,7 @@ you can then use and build again. This is hacky, and best to be avoided.
See the [relevant sections in the
# LaTeX
Arbitrary, one-off environments:
......@@ -701,8 +740,11 @@ Arbitrary, one-off environments:
# Misc.
- <>
- <>
- <>
- <>
- <>
- <>
- <>
- <>
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment