Let’s talk about
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
importfrom 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
import is like… just a way to put expressions in other files, right? I don’t understand.
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.
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.fetchurlto obtain files by hash. The default is http://tarballs.nixos.org/. Given a hash type
htand 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-outputsis also turned on).
The difference between this option and
keep-derivationsis that this one is “sticky”: it applies to any user environment created while this option was enabled, while
keep-derivationsonly applies at the moment the garbage collector is run.
I still don’t understand
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
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:
restrict-evalis] set to
true, the Nix evaluator will not allow access to any files outside of the Nix search path (as set via the
NIX_PATHenvironment variable or the
-Ioption), or to URIs outside of
I learn about
sandbox, which does the thing you’d expect – fake file system, restricted
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 read the entire manual.
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
- 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