I’ve just spent the morning reading through some documentation and tutorials for nix, trying to figure out what it is, whether it’s cool, and whether I should be using it. Also, trying to figure out what this lix thing is. And of course, this is a dependency chain — I started out at the last element and, before I could answer that, I had to investigate the one before it, and so on. Why did I list it out this way? Because investigation is a stack, and I am reading out my stack by popping elements off it.
So:
- lix is a fork (? schism?) from nix, with interoperability and a groovy color palette. Its big deal seems to be that the project starts from a position of social justice, which is, I guess?, the reason for the schism?, and different from nix?
- I can imagine wanting to use it, but I don’t think I need to do that yet, particularly because it’s freakin’ complicated. The last thing I need to do right this second is introduce yet another programming language to my process.
- It is pretty cool, and if I were still working in an enterprise environment, I’d be leaning hard on the systems, dev ops, and testing teams to get the whole engineering group on board yesterday.
- It is a way to define specific software environments for portability and reproducibility. Kind of like how a Dockerfile specifies how to build a Docker image, and then that image represents a fixed environment, nix is a way to define all the packages that get mixed together into an environment. It’s way more expressive than a Dockerfile, which is essentially YAML; nix is more akin to LISP or shell scripting. Since I do not use an emacsitor to work on my files, it’s a pretty big mental burden for me to hold all of the nix stuff in my head. Looking at some documentation on the Swift tools, it looks like it’d be useful for reproducing a specific build, and maybe (?) avoiding the problem of mirroring? So, cool?