all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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


             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

* 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 external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.