Nix and GHC package database management: automatic vs custom database

The goal is to decide whether to allow Nix to automatically populate the GHC package database from the Nix store or to override it with a custom database location for incremental Haskell builds.

Nix creates pure build environments that isolate GHC and its dependencies, placing the package database in the Nix store rather than the usual Cabal or Stack user database. This separation means that using Cabal or Stack commands outside the Nix shell can lead to mismatched package databases and potential build failures, and the exact behavior may shift between different Nixpkgs releases.

Community discussions show mixed approaches: some projects accept Nix’s default management, while others explicitly set GHC_PACKAGE_PATH to maintain control over package registration, raising questions about how each choice affects incremental build cache validity and long‑term reproducibility.

What are the trade‑offs of using Nix’s default package database versus a custom database managed via GHC_PACKAGE_PATH? How does each approach influence incremental build cache validity and reproducibility across Nixpkgs versions?