README tweaks and pruning

This commit is contained in:
Richard Marko 2020-12-30 14:46:13 +01:00
parent e7c1aa7a7b
commit 3e043dc99d
3 changed files with 21 additions and 27 deletions

View File

@ -1,12 +1,10 @@
hnix-store
===========
# hnix-store
A Haskell interface to the [Nix] store.
[Nix]: https://nixos.org/nix
Rationale
-----------
## Rationale
`Nix` can conceptually be broken up into two layers, both (perhaps
unfortunately) named "Nix": The expression language and the store.
@ -33,36 +31,33 @@ implementations planned:
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`
* A `remote` 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
----------
## Packages
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
several Haskell packages.
### [hnix-store-core]
Contains 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-remote]
[Nix] worker protocol implementation for interacting with remote Nix store
via `nix-daemon`.
[hnix-store-core]: ./hnix-store-core
[hnix-store-remote]: ./hnix-store-remote

View File

@ -1,5 +1,4 @@
hnix-store-core
=================
# hnix-store-core
Core effects for interacting with the Nix store.
@ -10,7 +9,6 @@ on the store.
[System.Nix.StorePath]: ./src/System/Nix/StorePath.hs
Tests
======
# Tests
- `ghcid --command "cabal repl test-suite:format-tests" --test="Main.main"`

View File

@ -1,9 +1,10 @@
hnix-store-remote
=================
# hnix-store-remote
Nix worker protocol implementation for interacting with remote Nix store
[Nix] worker protocol implementation for interacting with remote Nix store
via `nix-daemon`.
[Nix]: https://nixos.org/nix
## API
[System.Nix.Store.Remote]: ./src/System/Nix/Store/Remote.hs