Skip to content
Haskell implementation of the nix store API
Branch: master
Clone or download
Latest commit 671d3c5 Apr 5, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
hnix-store-core Derive Ord for StorePath Apr 5, 2019
hnix-store-remote hnix-store-remote README: fix example Mar 28, 2019
.envrc Lorri + direnv. Mar 20, 2019
.gitignore cabal new gitignores. Mar 20, 2019
LICENSE Copyright Apr 24, 2018 README: Elaborate on project goals and layout. May 14, 2018
cabal.project add cabal.project Jul 16, 2018
default.nix Fix build on GHC 8.4 Mar 22, 2019
overlay.nix Build expressions. Mar 9, 2019
shell.nix Build expressions. Mar 9, 2019


A Haskell interface to the Nix store.


Nix can conceptually be broken up into two layers, both (perhaps unfortunately) named "Nix": The expression language and the store. The semantics of the expression language fundamentally depend on the store, but the store is independent of the language. The store semantics provide the basic building blocks of Nix: content-addressed files and directories, the drv file format and the semantics for building drvs, tracking references of store paths, copying files between stores (or to/from caches), distributed builds, etc.

The goal of hnix-store is to provide a Haskell interface to the Nix store semantics, as well as various implementations of that interface. Though the current primary client is hnix, an effort to reimplement the Nix expression language in Haskell, this project is meant to be generic and could be used for a number of other cases of interaction with the Nix store (e.g. a shake backend that emitted each build action as a store derivation). Currently, there are three implementations planned:

  • A mock store which performs no IO whatsoever, for unit testing.
  • A readonly store, which defers to another implementation for readonly effects (such as querying whether some path is valid in the store, or reading a file) but performs mutating effects in-memory only (for example, computing the store path a given directory would live at if added to the store, without actually modifying anything).
  • A daemon store, which implements the client side of the Nix daemon Unix domain socket protocol, allowing full interaction with the store on a system with the C++ daemon installed.

While this project is in the early stages of development, the daemon store can be seen as something of a road map: We want to express and implement all of (and only) the useful functionality available to a client of the existing daemon protocol.

Note that there are currently no plans for hnix-store to include an implementation which directly mutates the filesystem and database of the Nix store.


In the interest of separating concerns, this project is split into several Haskell packages. The current expectation is at least one package, hnix-store-core, containing the core effect types and fundamental operations combining them, agnostic to any particular effectful implementation (e.g. in-memory, talking to the Nix daemon in IO, etc.), with the actual implementations in a different package. Whether each implementation gets its own package or not remains to be seen.

The intent is that core business logic for a project that needs to interact with the Nix store can simply depend on hnix-store-core, and only at the very edges of the system would it be necessary to bring in a specific implementation.

You can’t perform that action at this time.