Nix Derivation Madness

> 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.

Eh. This can be applied to so many technologies that run the world..

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.

Isn't there a way to transpile the scripts from Nix to Guix?

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.)

I feel the same about HCL in Terraform. The tool is perfect, the language is bollocks.

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.

It's not to hard to translate manually, but since the dependency tree is massive it doesn't seem feasible to do wholesale.

AFAIK Guix uses parts of Nix as a backend.

Guix uses the sandboxing logic iirc

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.

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

Guix uses a fork of the nix daemon

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.

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.