mirror of
https://github.com/haskell-nix/hnix-store.git
synced 2024-09-11 18:05:56 +03:00
parent
da0f19a65f
commit
262cdc7f58
57
README.md
57
README.md
@ -5,9 +5,64 @@ A Haskell interface to the [Nix] store.
|
||||
|
||||
[Nix]: https://nixos.org/nix
|
||||
|
||||
Rationale
|
||||
-----------
|
||||
|
||||
`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.
|
||||
|
||||
[hnix]: https://github.com/haskell-nix/hnix
|
||||
|
||||
Packages
|
||||
----------
|
||||
|
||||
* [hnix-store-core]: Core effects for interacting with 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.
|
||||
|
||||
[hnix-store-core]: ./hnix-store-core
|
||||
|
Loading…
Reference in New Issue
Block a user