maurice/snix
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs(architecture): drop Figures and dangling footnote

Browse source 
Change-Id: Ibe4992b54fc42b8965bef4727d00373f1114c90f
Reviewed-on: https://cl.snix.dev/c/snix/+/30267
Autosubmit: Florian Klink <flokli@flokli.de>
Tested-by: besadii
Reviewed-by: Ryan Lahfa <masterancpp@gmail.com>
This commit is contained in:
Florian Klink 2025-03-24 01:36:47 +00:00 • committed by clbot
parent db873cce39
commit b054d6d90f
2 changed files with 0 additions and 70 deletions
Download patch file Download diff file Expand all files Collapse all files

10
snix/docs/src/architecture.md
View file

@ -90,13 +90,3 @@ It'd also be possible to write a FUSE implementation on top of the RPC
interface, exposing a lazily-substituting /nix/store mountpoint. Using this in
remote build context dramatically reduces the amount of data transferred to a
builder, as only the files really accessed during the build are substituted.
## Figures
```plantuml,format=svg
{{#include figures/component-flow.puml}}
```
[^1]: There have already been some discussions in the Nix community, to switch
to REAPI:
https://discourse.nixos.org/t/a-proposal-for-replacing-the-nix-worker-protocol/20926/22

60
snix/docs/src/figures/component-flow.puml
View file

@ -1,60 +0,0 @@
@startuml
title Tvix build flow
actor User
participant CLI
participant "Coordinator" as Coord
participant "Evaluator" as Eval
database Store
participant "Builder" as Build
note over CLI,Eval
Typically runs locally on the invoking machine
end note
/ note over Store, Build
Can be either local or remote
end note
User-->CLI: User initiates build of `hello` (analogous to `nix-build -f '<nixpkgs>' -A hello`)
CLI-->Coord: CLI invokes coordinator
Coord-->Eval: Sends message to start evaluation of `<nixpkgs>` (path lookup) with attribute `hello`
note right: The paths to the evaluator are local file system paths
Coord<--Eval: Yields derivations to be built
note right
Immediately starts streaming derivations as they are instantiated across
the dependency graph so they can be built while the evaluation is still running.
There are two types of build requests: One for regular "fire and forget" builds,
and another for IFD (import from derivation).
These are distinct because IFD needs to be fed back into the evaluator for
further processing while a regular build does not.
end note
loop while has more derivations
Coord-->Store: Check if desired paths are in store
alt Store has path
Coord<--Store: Success response
else Store does not have path
Coord-->Build: Request derivation to be built
alt Build failure
Coord<--Build: Fail response
note left: It's up to the coordinator whether to exit on build failure
else Build success
Build-->Store: Push outputs to store
Build<--Coord: Send success & pushed response
end
end
end
CLI<--Coord: Respond success/fail
User<--CLI: Exit success/fail
@enduml