> The road to Nix enlightenment is no joke and full of dragons.
Nix was a great research project. Now is the time to rewrite it from the ground up.
> The road to Nix enlightenment is no joke and full of dragons.
Nix was a great research project. Now is the time to rewrite it from the ground up.
The core store layer is quite small, and I am trying to thoroughly document it, with all 3 of:
- a more "academic" spec of what it does
- nuts-and-bolts JSON schema for many data types
- JSON golden tests instead of C++ literals in the unit tests as often as possible.
I hope this will make additional store layer easy to churn out.
(The "hash derivation modulo" that is so fiddly described in this blog post can be dropped in a world where we no longer have input addressing, and just have content-addressing. Or, in a world where we have a new, simpler type of input-addressing instead.)
Well, there's Guix as an alternative if you want a similar concept but different implementation philosophy. For me the major disadvantage of Guix is lack of package availability compared to Nix.
I really wish Guix worked on macOS. Nix-Darwin and home-manager have been game changers -- sharing much config and tooling between my Mac, arch, and nixos machines has been a blessing.
Isn't there a way to transpile the scripts from Nix to Guix?
In practicing no because in the end it generally takes a human intelligence to fully understand the requirements of a particular program, sanity check everything, get the right dependency versions and fix build errors. For code library repositories like rust, importing is fairy automated since everything is neat, tidy, and regular. But end user applications are more often than not a pain in the ass
That would be possible. The main problem there is that nixpkgs, the package repository one would want to translate, uses a good chunk of specialized build infrastructure (parts in nix, some in rust/Perl/Python) that is designed for nix (the package manger).
Some other semi-specific parts, like stdenv bootstrapping, are also a bit more complex than just some nix build instructions.
It's not to hard to translate manually, but since the dependency tree is massive it doesn't seem feasible to do wholesale.
[dead]
AFAIK Guix uses parts of Nix as a backend.
Guix uses a fork of the nix daemon
Guix uses the sandboxing logic iirc
I feel the same about HCL in Terraform. The tool is perfect, the language is bollocks.
Pulumi may be what you're looking for. Same concept as Terraform, and many of its provider libraries are just wrappers around Terraform provider libraries, but you can use a variety of common programming languages to declare your desired state, rather than HCL.
Yeah, I tried it briefly some time ago and it seems like a solution.
It has been rewritten a few times already. The "fixed output hash" is a dirty optimisation hack borne out of real-world needs and not a research idea.
Eh. This can be applied to so many technologies that run the world..