For somebody who hasn't used Nix yet, but heard good things about it, why use Tvix instead of Nix? The page didn't seem to mention the reason(s) behind the project.
I would recommend against using Tvix at this time, but if you are wondering why they wrote it, they wrote an article: https://tvl.fyi/blog/rewriting-nix
The goals they list are:
Creating an alternative implementation of Nix that is fully compatible with nixpkgs.
No explanation needed.
More efficient Nix language evaluation, leading to greatly increased performance.
The Nix language is evaluated whenever doing the Nix equivalent of installing a package, or rebuilding your configuration. Note that most of the time it's "fast enough" but the authors of Tvix are doing more with the Nix language (which leads into)
No more strict separation of evaluation and build phases: Generating Nix data structures from build artefacts ("IFD") should be supported first-class and not incur significant performance cost.
and
Well-defined interaction protocols for how the three different components (evaluator, builder, store) interact.
As it currently works, the Nix language is evaluated to something called a derivation, which is a specific format for defining how to build something (including a list of dependencies). The derivation is then used to actually build the artifact. This is about when you want the metaphorical snake to eat its tail and have the results of a derivation be more nix language to evaluate.
A builder implementation using OCI instead of custom sandboxing code.
Hermetic builds require some sandboxing; Using OCI containers seems like an obvious choice, but didn't exist when Nix was first created.
I know full well what OCI is. (Hint: it's a transparent attempt to be a NOT-docker and avoid infringing on whatever Docker Inc.'s latest monetization scheme is.)
Using this for what Nix is doing is absolute madness. Docker is madness in general, but dragging it into Nix's core is madness cubed.
"why yes, the open-source Apache-licensed implementation controlled by the linux foundation is just as commercial as the commercial thing! i'm so contrary and interesting!"
if you don't want docker-contributed code, here are some alternative implementations of the spec: https://github.com/opencontainers/runtime-spec/blob/main/imp... I believe nix could use one of these with some volunteer effort? Perhaps you could even be the one to purge the Docker heresy from the project!
(...in hindsight, i'm sorry for posting this, it's needlessly adversarial and picky. i was mad at something unrelated this morning and i shouldn't have taken that out on you.)
The implementation of Nix's build sandboxing is outside of the core focus of Nix. The macOS sandboxing code is famously buggy. Seems like a perfectly reasonable thing to leave to a battle-hardened, standardized, outside implementation to me.
It looks like they’ve factored out the main features of Nix into modules to allow for more flexibility regarding the implementation details of each underlying service.
Comments
For somebody who hasn't used Nix yet, but heard good things about it, why use Tvix instead of Nix? The page didn't seem to mention the reason(s) behind the project.
I would recommend against using Tvix at this time, but if you are wondering why they wrote it, they wrote an article: https://tvl.fyi/blog/rewriting-nix
The goals they list are:
No explanation needed.
The Nix language is evaluated whenever doing the Nix equivalent of installing a package, or rebuilding your configuration. Note that most of the time it's "fast enough" but the authors of Tvix are doing more with the Nix language (which leads into)
and
As it currently works, the Nix language is evaluated to something called a derivation, which is a specific format for defining how to build something (including a list of dependencies). The derivation is then used to actually build the artifact. This is about when you want the metaphorical snake to eat its tail and have the results of a derivation be more nix language to evaluate.
Hermetic builds require some sandboxing; Using OCI containers seems like an obvious choice, but didn't exist when Nix was first created.
Presumably this would make this implementation Linux-only, since OCI isn't natively supported outside of Linux?
A complete non-starter, never in a thousand years am I gonna use something that requires a Docker installation for building derivations.
Maybe once you learn what OCI is, you'll rethink that ;)
I know full well what OCI is. (Hint: it's a transparent attempt to be a NOT-docker and avoid infringing on whatever Docker Inc.'s latest monetization scheme is.)
Using this for what Nix is doing is absolute madness. Docker is madness in general, but dragging it into Nix's core is madness cubed.
Would this be the equivalent of Mock (Fedora) or sbuild (Debian) pristine chroot builders? Containers are just fancy chroots.
"why yes, the open-source Apache-licensed implementation controlled by the linux foundation is just as commercial as the commercial thing! i'm so contrary and interesting!"
if you don't want docker-contributed code, here are some alternative implementations of the spec: https://github.com/opencontainers/runtime-spec/blob/main/imp... I believe nix could use one of these with some volunteer effort? Perhaps you could even be the one to purge the Docker heresy from the project!
OCI is not an attempt for a useful, general-purpose, open containerization standard.
It is an attempt at an open-source "just good enough" Docker clone.
You understand the difference?
(...in hindsight, i'm sorry for posting this, it's needlessly adversarial and picky. i was mad at something unrelated this morning and i shouldn't have taken that out on you.)
The implementation of Nix's build sandboxing is outside of the core focus of Nix. The macOS sandboxing code is famously buggy. Seems like a perfectly reasonable thing to leave to a battle-hardened, standardized, outside implementation to me.
Podman is also an option.
No, I don't want "dollar store Docker" either.
huh?
"evaluated", but with a small key shift on qwerty
Oh, I see. I was having a hard time with that one. Thanks!
presumably meant to be 'is evaluated'.
typo, fixed.
It looks like they’ve factored out the main features of Nix into modules to allow for more flexibility regarding the implementation details of each underlying service.
Not ready, so not a good reason to use it yet.