Now that I’ve reached the end of the manual, I want to reflect a little bit on my journey so far.
What have I learned?
I have learned a lot, really.
But I feel like I haven’t learned enough to like… use Nix.
I mean, yeah, I know how to install git or whatever.
I felt like – and this is entirely subjective – the manual spent most of its time describing how to use Nix as a system package manager, a replacement for apt-get or whatever. And very little time describing either (1) how Nix works or (2) the things that you can actually do with Nix. I mean, that awesome nix-shell -i thing was totally buried in the command reference.
On (1), I think I would have preferred something like “Nix from first principles” (does this exist?) where I start from nothing and gradually introduce the lowest level commands. Maybe I should read the original thesis.[pdf]
So I don’t really understand yet how I would incorporate Nix into my own software development cycle. Because although I have a superficial understanding of how to write derivations, I still don’t understand anything about integrating Nix with language-specific package managers, and that’s sort of… vital.
I have written tons of programs that use cabal or npm or gem or pip or opam or whatever and I don’t understand how to make Nix play well with those dependencies. I’ve only learned how to download a tarball and run make. That’s not really a workflow that figures heavily in my personal software engineering story.
I imagine that reading the Nixpkgs manual will explain how all of that works. At least, I hope that reading the Nixpkgs manual will explain how all of that works. And then I will “actually” be able to use Nix.
But back to what I did learn:
I learned that the Nix user interface is still pretty bad. Low hanging user-friendly commands like nix install just don’t exist. That’s not… great. nix eval is weirdly hostile. There is no nix pp, which is something that would have made this journey more pleasant.
I learned that Nix appears to make an effort to decouple itself from the official Nixpkgs repository. I like this: I think it’s great that I can make my own repository of in-house software and it won’t feel like a second class citizen. Except… I don’t actually have any idea how I would do that without heavily depending on all of the Nixpkgs infrastructure. It’s hard for me to see where the lines are between Nix and Nixpkgs, especially given the apparent importance and complexity of stdenv. It seems like it would be very hard to define my own “minimalist” ianpkgs without importing large swaths of Nixpkgs. Maybe it’s easy! I just haven’t really learned how to do it yet.
I also learned that you can read the entire Nix manual and still not know what “derivation” means. I still could not give you a precise definition. Is it its own unique special builtin type? I don’t know. I also don’t know what operations cause derivations to be built or “realised” or whatever Nix calls it. I don’t understand why sometimes “derivation” means “a bunch of attributes” and sometimes it means “a .drv file” and sometimes it means “the thing that the function derivation returns.”
I’ll get there. I hope.
But for now, I think I might have to take a little time off from learning Nix.
The galaxy needs me.
$ keen4