Let’s talk about nix.conf.

This is another reference section – seems like we’re going through all the options. I’m going to read this list and make notes in anything that sounds interesting.

Chapter 24. Files

I encounter an unfamiliar term: “restricted evaluation mode.” Seems like I can prevent Nix from talking to arbitrary HTTP sources? That seems neat if I’m like… being paid to use Nix. I can ensure that things only exist on my private cache server or something. Neat.

By default, Nix allows you to import from a derivation, allowing building at evaluation time. With [allow-import-from-derivation] set to false, Nix will throw an error when evaluating an expression that uses this feature, allowing users to ensure their evaluation will not require any builds to take place.

Okay. Do not understand that one. “Building at evaluation time”? What does this mean? Why is this called allow-import-from-derivation? import is like… just a way to put expressions in other files, right? I don’t understand.

I learn allow-new-privileges will allow me to run things like sudo from a build script. That’s… something? I encounter another unfamiliar term: “sandbox builds.” I’m curious how this restriction actually works but it’s Linux-specific so I don’t bother looking into it.

I learn hashed-mirrors, which feels very important, and I’m surprised that it hasn’t been mentioned anywhere before:

A list of web servers used by builtins.fetchurl to obtain files by hash. The default is http://tarballs.nixos.org/. Given a hash type ht and a base-16 hash h, Nix will try to download the file from hashed-mirror/ht/h. This allows files to be downloaded even if they have disappeared from their original URI.

That’s really neat! And like… definitely if I were trying to use Nix in a production environment, I would want to, you know, set one of those up myself, so that I would not have to depend on The Internet. I’m kind of surprised that this is buried here.

Ah, I finally understand what keep-derivations does: it means “keep the .drv files around until you get rid of the things they build.” Okay.

Keeping derivation around is useful for querying and traceability (e.g., it allows you to ask with what dependencies or options a store path was built), so by default this option is on. Turn it off to save a bit of disk space (or a lot if keep-outputs is also turned on).

There’s also keep-env-derivations…

The difference between this option and keep-derivations is that this one is “sticky”: it applies to any user environment created while this option was enabled, while keep-derivations only applies at the moment the garbage collector is run.

Interesting.

I still don’t understand keep-outputs.

If true, the garbage collector will keep the outputs of non-garbage derivations.

In general, outputs must be registered as roots separately. However, even if the output of a derivation is registered as a root, the collector will still delete store paths that are used only at build time (e.g., the C compiler, or source tarballs downloaded from the network). To prevent it from doing so, set this option to true.

Why… how is this different from “do not collect garbage”?

The first sentence makes me think it means “prevents the garbage collector from deleting things you installed.” I hope the garbage collector will keep the outputs of derivations! I care a lot more about the outputs than the derivations!

But then the examples in the separate paragraph makes me think it means “prevents the garbage collector from deleting any files.” I am very confused by this. Weirdly, this is like – the first option I remember encountering. And having read the entire manual I still don’t understand what it means. That’s not great!

plugin-files! First I’ve heard of this. Nix plugins! Who would have thought?

Ah, here’s “restricted evaluation mode” explained:

If [restrict-eval is] set to true, the Nix evaluator will not allow access to any files outside of the Nix search path (as set via the NIX_PATH environment variable or the -I option), or to URIs outside of allowed-uri.

I learn about sandbox, which does the thing you’d expect – fake file system, restricted /proc, etc.

Currently, sandboxing only work on Linux and macOS. The use of a sandbox requires that Nix is run as root (so you should use the “build users” feature to perform the actual builds under different users than root).

Okay. Neat that this exists. Definitely useful in a production environment. Probably not something I’m ever going to use.

I finish reading the rest of the options.

And… now what?

I’m done.

I read the entire manual.

Wow.

I’m done?

How can this be?

What do I do now?

I mean, I suppose I should probably check on my family.

But after that… maybe read the Nixpkgs manual?

No; I know what I have to do next: go through all of my “open questions” and see what my outstanding wonders are. And then unwonder them, one at a time. Exhales loudly.

  • What does allow-import-from-derivation do?
  • How can I set up my own “hashed mirror?”
  • How can I evaluate an option to see its current/default value?
  • What the hell does keep-outputs do?