Re: Tvix code structure

[Florian Klink <flokli@flokli•de>]

>>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).
>
>Even with different concepts for calculating output paths, I'd still
>assume our store paths will probably look very similar, and we might
>need to end up keeping other functionality too.
>
>I'd be more in favor of keeping `derivation` and `nar` a separate crate
>for now. I'll send a CL splitting out `StorePath` from `//tvix/store`,
>that should solve the immediate concerns w.r.t. things pulled into eval
>directly.
>
>We can make sure we split things up further once we get to actually
>talking to the store from nix-compat or cli (as a client).

Alright, I tried this, but obviously nixbase32 is a dependency on
StorePath.

Let's put both these things in `nix-compat`, but let's make sure this
stays a library-only crate. Having CLI entrypoints there would be
confusing.

I'll leave a potential move of `//tvix/derivation` and `//tvix/nar` to
there as a followup, I need to think a bit more about the ergonomics.