From: Florian Klink <flokli@flokli.de>
To: guix-devel@gnu.org
Subject: Nix Daemon protocol post / Tvix
Date: Mon, 30 Oct 2023 23:02:18 +0200 [thread overview]
Message-ID: <rdrshtntxxzrw2lirjzx33lqttnpvn5evllttxvmvd3kf3drg7@4x2ofykjx742> (raw)
Hey,
I stumbled across your post
https://guix.gnu.org/blog/2023/a-build-daemon-in-guile/.
I'm working on Tvix (https://tvix.dev/), a reimplementation of Nix in
Rust.
Different components are nicely separated, some of the nix-specific
protocols and formats are developed in a independent, intended to be
general-purpose `nix-compat` crate that doesn't depend on Tvix itself.
All with hopefully comprehensive documentation and a lot of test cases.
Tvix can already evaluate bigger chunks of nixpkgs the same way as Nix,
and come up with the same calculated output paths :-)
Some of the protcols are implemented in a nicer fashion, while providing
a Nix-compatible "view" into the system.
For example, tvix-store is using a content-addressed merkle storage DAG
(tvix-castore) under the hood, allowing partial substitution and store
path subtree sharing.
However we can still provide a Nix-compatible view into all this, so can
synthesize NAR Archives and NARInfo files for a given store path on
demand, if we want to. We currently use the HTTP Binary cache protocol
as a store interface for Nix (via `nar-bridge`, which spins up a
webserver).
At some point, we now also want to implement the daemon protocol - both
a client and server, to allow talking to Nix more directly - be it a
"remote store", or just querying the local Nix store for certain
information. This is so far mostly oriented towards store operations (as
we didn't do too much work on the Builder interface yet)
Nevertheless, I think we should collaborate.
Be that:
- just a simple exchange of notes about the behaviour of the protocol
and certain operations
- discussions about designing new protocols, ensuring interop between
tvix-store and guix stores (there's some ideas for P2P substitution)
- or even collaboration and work on getting tvix-store (and tvix-build,
once it's there) to work with a Guile frontend :-)
I think we're sharing a lot of common interest and would like to start
having these conversations :-)
Cheers,
flokli
Some links:
- Tvix status update from NixCon 2023
(https://media.ccc.de/v/nixcon-2023-35254-tvix)
- Tvix Website: https://tvix.dev/
- Code: https://code.tvl.fyi/tree/tvix
next reply other threads:[~2023-10-31 11:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-30 21:02 Florian Klink [this message]
2023-11-16 15:14 ` Nix Daemon protocol post / Tvix Ludovic Courtès
2023-11-16 19:23 ` Ensuring daemon interop, maybe also store layer standardization? John Ericson
2023-11-16 20:52 ` Florian Klink
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=rdrshtntxxzrw2lirjzx33lqttnpvn5evllttxvmvd3kf3drg7@4x2ofykjx742 \
--to=flokli@flokli.de \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).