TVL depot development (mail to
 help / color / mirror / code / Atom feed
* Tvix code structure
@ 2023-01-30  7:27 Vincent Ambo
  2023-01-31 11:01 ` Florian Klink
  0 siblings, 1 reply; 3+ messages in thread
From: Vincent Ambo @ 2023-01-30  7:27 UTC (permalink / raw)
  To: depot

We should start thinking about how to clean up the code structure of 
Tvix, some things are a bit ad-hoc. It's not a problem right now, and 
not something we need to fix in the next week or so, but something to 
keep in the back of our minds.

Tvix currently consists of the following subprojects:

* //tvix/eval: Language evaluator with no knowledge about building, 
dependencies and so on. It is just an implementation of the Nix 
language, the pure builtins, and some generalised impure builtins behind 
the `EvalIO` interface.

* //tvix/serde: Implementation of a serde::Deserializer using 
//tvix/eval to deserialise Rust data structures from Nix code. Can be 
used for e.g. tools that use configuration files written in Nix.

* //tvix/derivation: Implementation of data structures for the Nix 
derivation concept, and serialisation (to ATerm)/validation logic.

* //tvix/nar: A serialiser for the NAR archive format (*not* a 

* //tvix/nix_cli: C++ Nix compatibility CLI, using clap to parse the 
same argument structure as C++ Nix. This is not wired up to anything 
right now.

* //tvix/proto: Evaluator proto only, not used at the moment.

* //tvix/store: Protobuf for stores, and initial implementation of the 
store service. However, also contains types like `StorePath` which are 
used in different places.

* //tvix/cli: Currently, Tvix REPL implementation and the place where 
things like `builtins.derivation` are implemented. Currently depends on 
almost everything from above (including e.g. the store *service*!)

I want the language evaluator to be independent from any build-related 
concerns (so that the language can be used for other use-cases). That 
means that //tvix/eval should never depend on any of the crates 
implementing C++ Nix concepts, should not "know" about derivations (more 
than where absolutely necessary for correct functioning of the language, 
e.g. printing values) and so on. For this reason I've been resisting 
putting things like `builtins.derivation` into eval.

At the same time, putting it into a crate called "cli" also feels wrong. 
There's also clearly a bug in that //tvix/store implements a service, 
and exports a widely used type, and that ends up dragging in hundreds 
(!) of dependencies on any crate using that type.

My current thinking is that what we actually want is something like this:

* //tvix/eval: as above
* //tvix/serde: as above
* //tvix/nix-compat: types and logic related to compatibility with C++ 
Nix: NARs, derivations, store paths and so on.
* //tvix/store: store backend (!) implementation
* //tvix/cli: REPL and CLI interface tying the above together

This would involve merging the nar and derivation crates, and moving the 
store path logic in there, too, to create the nix-compat crate.

Doing this would also allow us to have a clear boundary where it's 
visible what is legacy from C++ Nix, and show where we have the ability 
to come up with substitute concepts (or decide that that is not necessary).

Any thoughts are welcome!


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2023-01-31 11:11 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-30  7:27 Tvix code structure Vincent Ambo
2023-01-31 11:01 ` Florian Klink
2023-01-31 11:11   ` Florian Klink

Code repositories for project(s) associated with this public inbox

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).