49b173786c
Nodes only have names if they're contained inside a Directory, or if
they're a root node and have something else possibly giving them a name
externally.
This removes all `name` fields in the three different Nodes, and instead
maintains it inside a BTreeMap inside the Directory.
It also removes the NamedNode trait (they don't have a get_name()), as
well as Node::rename(self, name), and all [Partial]Ord implementations
for Node (as they don't have names to use for sorting).
The `nodes()`, `directories()`, `files()` iterators inside a `Directory`
now return a tuple of Name and Node, as does the RootNodesProvider.
The different {Directory,File,Symlink}Node struct constructors got
simpler, and the {Directory,File}Node ones became infallible - as
there's no more possibility to represent invalid state.
The proto structs stayed the same - there's now from_name_and_node and
into_name_and_node to convert back and forth between the two `Node`
structs.
Some further cleanups:
The error types for Node validation were renamed. Everything related to
names is now in the DirectoryError (not yet happy about the naming)
There's some leftover cleanups to do:
- There should be a from_(sorted_)iter and into_iter in Directory, so
we can construct and deconstruct in one go.
That should also enable us to implement conversions from and to the
proto representation that moves, rather than clones.
- The BuildRequest and PathInfo structs are still proto-based, so we
still do a bunch of conversions back and forth there (and have some
ugly expect there). There's not much point for error handling here,
this will be moved to stricter types in a followup CL.
Change-Id: I7369a8e3a426f44419c349077cb4fcab2044ebb6
Reviewed-on: https://cl.tvl.fyi/c/depot/+/12205
Tested-by: BuildkiteCI
Reviewed-by: yuka <yuka@yuka.dev>
Autosubmit: flokli <flokli@flokli.de>
Reviewed-by: benjaminedwardwebb <benjaminedwardwebb@gmail.com>
Reviewed-by: Connor Brewster <cbrewster@hey.com>
|
||
|---|---|---|
| .. | ||
| protos | ||
| src | ||
| build.rs | ||
| Cargo.toml | ||
| default.nix | ||
| README.md | ||
//tvix/store
This contains the code hosting the tvix-store.
For the local store, Nix realizes files on the filesystem in /nix/store (and
maintains some metadata in a SQLite database). For "remote stores", it
communicates this metadata in NAR (Nix ARchive) and NARInfo format.
Compared to the Nix model, tvix-store stores data on a much more granular
level than that, which provides more deduplication possibilities, and more
granular copying.
However, enough information is preserved to still be able to render NAR and NARInfo when needed.
More Information
The store consists out of two different gRPC services, tvix.castore.v1 for
the low-level content-addressed bits, and tvix.store.v1 for the Nix and
StorePath-specific bits.
Check the protos/ subfolder both here and in castore for the definition of
the exact RPC methods and messages.
Interacting with the GRPC service manually
The shell environment in //tvix provides evans, which is an interactive
REPL-based gPRC client.
You can use it to connect to a tvix-store and call the various RPC methods.
$ cargo run -- daemon &
$ evans --host localhost --port 8000 -r repl
______
| ____|
| |__ __ __ __ _ _ __ ___
| __| \ \ / / / _. | | '_ \ / __|
| |____ \ V / | (_| | | | | | \__ \
|______| \_/ \__,_| |_| |_| |___/
more expressive universal gRPC client
localhost:8000> package tvix.castore.v1
tvix.castore.v1@localhost:8000> service BlobService
tvix.castore.v1.BlobService@localhost:8000> call Put --bytes-from-file
data (TYPE_BYTES) => /run/current-system/system
{
"digest": "KOM3/IHEx7YfInAnlJpAElYezq0Sxn9fRz7xuClwNfA="
}
tvix.castore.v1.BlobService@localhost:8000> call Read --bytes-as-base64
digest (TYPE_BYTES) => KOM3/IHEx7YfInAnlJpAElYezq0Sxn9fRz7xuClwNfA=
{
"data": "eDg2XzY0LWxpbnV4"
}
$ echo eDg2XzY0LWxpbnV4 | base64 -d
x86_64-linux
Thanks to tvix-store providing gRPC Server Reflection (with reflection
feature), you don't need to point evans to the .proto files.