(no title)
Aaronmacaron | 2 years ago
Eventhough I've used nix for years now, I have no deep understanding of nix and I'm a very curious person who always tries to understand how stuff actually works. Nix makes me feel really dumb. It makes me feel like when I was twelve and I "programmed" by cluelessly stitching together code examples from online tutorials. I don't really understand what's going on outside of the really common use cases for nix.
I read the entire nix docs but I think it's the kind of documentation that's only useful if you already kind of get what's going on. It feels like you have to gather the knowledge from various random blogs. Last time I checked there surprisingly was not a single book which covers nix. I feel like a comprehensive book which teaches nix from the ground up and explains all the different ways of using nix would really help me and I would purchase such a book without hesitation if it existed.
teekert|2 years ago
Edit, I put in the request if you feel like upvoting: [0]
[0] https://www.reddit.com/r/3Blue1Brown/comments/133zoxd/commen...
whatwhaaaaat|2 years ago
Aaronmacaron|2 years ago
Nowadays, I just use nix (the package manager) on top of PopOS.
thomastjeffery|2 years ago
rustybolt|2 years ago
chriswarbo|2 years ago
Nix is fundamentally just a build system. It's based around `.drv` files ("derivations", which are like a Makefile rule). These are text files containing a system type (e.g. x86_64-linux), the path to an executable, a list of string arguments to give it and a key/value map of strings to use as environment variables. Those basically form a declarative version of an `exec` syscall.
Each .drv file also specifies some paths as its "outputs", and may optionally specify some "inputs": an input is either a raw file path, or a pair of [path to another .drv file, name of output].
The basic operation in Nix is a "build", like `nix-build /nix/store/...foo.drv`, which tells Nix to produce that derivation's output paths. Nix does this as follows:
- Look in that .drv file to find its output paths. If they already exist on the filesystem, print the paths and halt.
- If some of the output paths don't exist, query any configured binary caches to see if they have those paths. If so: download them, print the paths and halt.
- If some outputs don't exist, and aren't in any configured cache, then Nix will need to execute the derivation's command...
- First Nix checks that all the inputs referenced as raw files exist; if not, it exits with an error.
- Next Nix checks whether all of the inputs which reference other .drv files exist. Any which don't exist will first be built by following these steps (and so on, recursively).
- Once all of the "inputs" exist, Nix will run the derivation's executable (maybe in a sandbox, but that's not important)
- When the executable has finished, Nix will check whether all of its output paths now exist. If not, it prints an error message and exits. If they do exist, it prints the paths and halts.
That's the core idea of what Nix is doing: it's a way to specify individual command invocations, create dependencies between commands using the paths of their outputs, and allowing parts of such dependency trees to be skipped by downloading the desired outputs directly from a cache instead. It's like Make, but spread across multiple files.
The "magic trick" that makes Nix special is that the path of every .drv file must contain a hash of its contents. Since .drv files can reference each other by their paths, these hashes form a Merkle tree which completely specifies the entire dependency graph of each derivation (similar to how a git commit includes the commit ID of its parents, and hence specifies its entire history).
This is a remarkably powerful and general approach to specifying the contents of files/folders. The downside is that it's tedious to write all of these .drv files by hand (especially calculating the hashes), so Nix comes with a simple scripting language to generate them. We can use the -E argument of nix-build to specify a "Nix expression", which will generate a .drv file to build (the `derivation` function will default to specifying a single output called "out"):
Other projects, like Nixpkgs, build on top of this foundation, by defining elaborate libraries of Nix expressions to generate .drv files for the build commands of thousands of different software projects. (Note that Nixpkgs doesn't use `/bin/sh` like I did; it specifies the URL and SHA256 of a few "bootstrap binaries" for Bash, GCC, etc. and those are used to define everything else)