Nix and GHC package database management: automatic vs custom database

Answer

Use Nix’s default, read‑only package database when reproducibility across machines and Nixpkgs versions is the priority. Override it with a custom database via GHC_PACKAGE_PATH only if you need faster incremental builds and can accept the responsibility of keeping the database in sync with the Nix expression.

Likely Explanation

The default Nix approach stores the GHC package database inside the Nix store, which is immutable and uniquely identified by the hash of all inputs. This guarantees that every developer and CI job sees exactly the same set of package IDs, so a build that succeeds locally will also succeed remotely, regardless of later Nixpkgs updates (as long as the same derivation is used). The downside is that any change to a Haskell source file forces Nix to treat the derivation as changed, often triggering a rebuild of the whole closure and slowing inner‑loop development.

When you point GHC_PACKAGE_PATH to a mutable directory, GHC can register packages there without re‑linking against the Nix store. This lets tools like cabal build or stack build reuse previously compiled objects, giving a noticeable speed‑up for small edits. However, the database now lives outside Nix’s purity guarantees: it can accumulate packages that were not declared in the .nix, drift from the store‑provided versions, and become invalid if the underlying GHC or core library paths change in a new Nixpkgs revision.

Confirmed Facts (from research)

• Nix defaults pin the package database to a read‑only store path, preventing "pollution" from local user databases.
• Default management avoids hidden dependencies but can make incremental development slower because each change may rebuild the Nix closure.
• Custom databases via GHC_PACKAGE_PATH enable mutable package registration, which can speed up incremental builds by avoiding constant re‑linking.
• Using GHC_PACKAGE_PATH introduces impurity; the local build state may diverge from the Nix expression, breaking reproducibility.
• Nixpkgs version shifts can invalidate a custom database if the GHC version or core library paths change, requiring a full reset.

Steps for This Case

1. Default (recommended for reproducibility): Simply enter nix-shell or use nix develop. No extra configuration is needed; GHC will automatically use the store‑located package database.
2. Custom database (if faster incremental builds are needed):
   1. Choose a writable directory, e.g. $HOME/.ghc-custom-db.
   2. Initialize it: ghc-pkg init $HOME/.ghc-custom-db.
   3. Export the path: export GHC_PACKAGE_PATH=$HOME/.ghc-custom-db (or prepend it if you want to keep the store DB as a fallback).
   4. Register the packages you need: ghc-pkg register /nix/store/...-package.conf for each dependency, or let Cabal/Stack do it via cabal v2-build or stack build after setting the variable.
   5. When you update the Nixpkgs revision that changes GHC or core libraries, delete and re‑initialize the custom database to avoid mismatches.

Missing Diagnostic Detail

Are you primarily using cabal (with v2-build or new-build) or stack for your Haskell builds? The answer affects whether GHC_PACKAGE_PATH is honoured and how you should register packages, which could change the recommendation.