Tvix explicitly targets stable Nix features, so supporting Flakes is a non-goal.
Many users have a poor understanding of what Flakes _actually_ are: They are a bit of UX glue on top of existing Nix features:
- Input/output schemas for `flake.nix`
- A lock file format
- CLI features to work with the two above
It's entirely feasible to build out a Flake user interface & evaluation support on top of Tvix without making it a first-class evaluator feature.
See https://github.com/edolstra/flake-compat for prior art.
The key point of Tvix _not_ having support for Flakes is to not make special snowflake evaluator features that are tied in with it.
> Tvix explicitly targets stable Nix features, so supporting Flakes is a non-goal.
Except that it rolls its own CA store[1], which is also not a stable Nix feature. One could argue that it has to roll its own store because Nix wants to own the store, but implementing a shadow version of an experimental feature makes the "they're just targeting stable features" part ring rather hollow.
> The key point of Tvix _not_ having support for Flakes is to not make special snowflake evaluator features that are tied in with it.
That's not really how I read the authors' defense of this choice. It seems like they made it because they disagree with the design decision, and I consider that more defensible than the position you offer. I just wish they would make this information more central, and I will keep posting it in news items about Tvix because no one else is going to. There is no indication that the "Nix" they implement is many years old now, and when they do[2] indicate it, they are vague about why.
Flakes are a misfeature that adds a complicated layer of abstraction over an already not very simple system.
I follow some chats with lots of Nix beginners, and the amount of people that are now stuck in a flakes tarpit and have no understanding of the fundamentals of Nix (and no path to get there, really, in the course of normal usage) is depressing. Just the other day I saw someone post a 40 line Nix code snippet using flakes, pulling in 2 git repos apart from nixpkgs (because the barebones flakes are barely even usable without support libraries), all to make a simple nix-shell with a single package in there - and it didn't even work and they were unsure how to proceed with debugging.
In almost all chats with flakes proponents it also eventually turned out that what they want is something like niv, but integrated into the Nix binary, not all of the additional stuff that is attached to flakes.
Anyways, adisbladis' point is that Tvix does not need to support flakes in any way. If you really want to add these complications to your Nix code, you can implement everything flakes do in pure Nix (using e.g. the flakes-compat thing linked above).
Sure, and this is all fine, but it feels like this information gets buried or smoothed-over, and I think you strengthen your position by leading with it as a differentiator. Nobody new to Nix knows what targeting 2.3 means, but they likely know what flakes are, and you aren't doing a lot to make it clear why they should prefer a fast language evaluator to something that can handle flakes.
This seems to be from 2 years ago, a lot of things could have changed.
He seemed quite opinionated on flakes, but the only bad thing that I can see to flakes is that you cannot pass args to them, for imo no valid reason, you have to use the file+file protocol and update the inputs each time to have a reasonable way to pass parameters...
(Tvix developer here) 2 years after, Flakes are still what they are, IMHO, a pile of layering violations.
I do not see a path forward for them in Tvix before we get to fix them layer by layer, which Nix is trying to do (slowly?).
At some point, once we stabilize a bunch of things, I have some plans to do what I call the right design of Flakes, but it does not involve modifying completely the core of the interpreter to leak this implementation detail everywhere, but more make this a library concept.
Most flakes make it a pain to cross-compile, too, especially to platforms other than the "big four" ({aarch64,x86_64}-{linux,macos}), as compared to overlays.
(That said, the tooling around flakes is so much nicer that I still use and recommend them.)
asking nix to accept arbitrary args in flakes like asking to so random patch of rust code during compilation. to patch use cargo patch. that is analogy of flakes, when you thing how flakes make nix statically typed.
Many users have a poor understanding of what Flakes _actually_ are: They are a bit of UX glue on top of existing Nix features:
- Input/output schemas for `flake.nix`
- A lock file format
- CLI features to work with the two above
It's entirely feasible to build out a Flake user interface & evaluation support on top of Tvix without making it a first-class evaluator feature. See https://github.com/edolstra/flake-compat for prior art.
The key point of Tvix _not_ having support for Flakes is to not make special snowflake evaluator features that are tied in with it.