tvix: move store, castore & build to separate development infrastructure

The Tvix Store as a project has evolved away from TVL, existing as a separate, only partially overlapping community with different interests.

It's time to draw a line and split the projects: tvix-eval will remain in depot, and probably grow a separate store implementation just matches C++ Nix functionality. tvix-castore, and current tvix-store, move out of depot onto separate CI etc. infrastructure and depend on tvix-eval from there.

We'll have to figure out how to do this transition. My foremost concern is the exploding dependency closure of the store, which is impacting other parts of TVL infra (making channel bumps harder due to CI load, slowing down my local workflows etc.), so this relates to b/426.

This also is a blocker for other TVL infra changes I want to do, such as getting rid of Keycloak and OAuth.

We can figure out some transitionary scheme until tvix-store & co has found a way to organise its development somewhere else, for example I'm fine with having the code in depot for now and using Gerrit, but we'll want to exclude the relevant targets from our CI.

1. I suppose we have multiple issues here:

   1. //tvix has accrued a lot of dependencies, mainly via //tvix/*store, leading to multiple adverse effects. It seems that these are mostly technical problems we can solve without changing the scope of //tvix in depot.

      • //tvix/cli is quite expensive to build since it depends on //tvix/castore via //tvix/glue. This can be solved via an alternative store backend with fewer dependencies. I've started work on this at cl/12964, though I'm a bit short on time at the moment. (Implementing something like this should also enable us to design a “beyond EvalIO” interface which allows implementing store backends without worrying about the specifics of builtins.storePath, builtins.derivationStrict etc.) Hopefully untangling this reduces the annoyance of the //tvix workspace. If need be, we can always separate it again (i.e. make a store only workspace).
      • //tvix/clippy takes forever to build. This seems to be exarcerbated by the fact that this derivation doesn't (re)use the crate2nix infrastructure we have. Instead a cargoDeps tarball containing the entirity of //tvix/Cargo.lock has to be compiled. Not sure how to tackle this, but is probably fixable.

   2. Disable Keycloak. This would require untangling some services from it (e.g. panettone) and communicating to some users that they need to create an LDAP account. For drive by contributions, email still exists and we don't have many of them anyways, even //tvix doesn't have a big flux in contributors (yet).

   3. Finally, the social problem of an asymmetry between people working on //tvix/*store and people working on basically the rest of depot. I don't think this is necessarily the end of the world and may just be exacerbated by a period of inactivity from longstanding contributors. However, it definitely detracts from depot if its users are no longer interested in depot for depot nor interested in improving tooling and infrastructure. In this sense it is regrettable that we now have a formal separation between Tvix and TVL in general. I hope we can find a way to move beyond that other than just parting ways and garner some renewed interest in the larger project.

   sterni at 2025-02-02T21·14+00