One of my pet peeves is when people abuse the term “Nix” without qualification when trying to explain the various components of the Nix ecosystem.
As a concrete example, a person might say:
“I hate Nix’s syntax”
… and when you dig into this criticism you realize that they’re actually complaining about the Nixpkgs API, which is not the same thing as the syntax of the Nix expression language.
So one of the goals of this post is to introduce some unambiguous terminology that people can use to refer to the various abstraction layers of the Nix ecosystem in order to avoid confusion. I’ll introduce each abstraction layer from the lowest level abstractions to the highest level abstractions.
Another reason I explain “Nix” in terms of these abstraction layers is because this helps people consult the correct manual. The Nix ecosystem provides three manuals that you will commonly need to refer to in order to become more proficient:
- The Nix manual
- The Nixpkgs manual
- The NixOS manual
… and I hope by the end of this post it will be clearer which manual interests you for any given question.
Edit: Domen Kožar pointed out that there is an ongoing effort to standardize terminology here:
I’ll update the post to match the agreed-upon terminology when that is complete.
Layer #0: The Nix store
I use the term “Nix store” to mean essentially everything you can
manage with the nix-store command-line tool.
That is the simplest definition, but to expand upon that, I mean the following files:
- Derivations:
/nix/store/*.drv - Build products:
/nix/store/*without a.drvextension - Log files:
/nix/var/log/nix/drvs/** - Garbage collection roots:
/nix/var/nix/gcroots/**
… and the following operations:
Realizing a derivation
i.e. converting a
.drvfile to the corresponding build products usingnix-store --realiseAdding static files to the
/nix/storei.e.
nix-store --addCreating GC roots for build products
i.e. the
--add-rootoption tonix-storeGarbage collecting derivations not protected by a GC root
i.e.
nix-store --gc
There are other things the Nix store supports (like profile management), but these are the most important operations.
CAREFULLY NOTE: the “Nix store” is independent of
the “Nix language” (which we’ll define below). In other words, you could
replace the front-end Nix programming language with another language
(e.g. Guile scheme, as Guix does). This is because the Nix derivation
format (the .drv files) and the nix-store
command-line interface are both agnostic of the Nix expression language.
I have a talk which delves a bit more into this subject:
Layer #1: The Nix language
I use the term “Nix language” to encompass three things:
- The programming language: source code we typically store in
.nixfiles - Instantiation: the interpretation of Nix code to generate
.drvfiles - Flakes: pure evaluation and instantiation caching
To connect this with the previous section, the typical pipeline for converting Nix source code to a build product is:
Nix source code (*.nix) │ Nix language
↓ Instantiation ├─────────────
Nix derivation (/nix/store/*.drv) │
↓ Realization │ Nix store
Nix build product (/nix/store/*) │In isolation, the Nix language is “just” a purely functional programming language with simple language constructs. For example, here is a sample Nix REPL session:
nix-repl> 2 + 2
4
nix-repl> x = "world"
nix-repl> "Hello, " + x
"Hello, world"
nix-repl> r = { a = 1; b = true; }
nix-repl> if r.b then r.a else 0
1However, as we go up the abstraction ladder the idiomatic Nix code we’ll encounter will begin to stray from that simple functional core.
NOTE: Some people will disagree with my choice to
include flakes at this abstraction layer since flakes are sometimes
marketed as a dependency manager (similar to niv). I don’t
view them in this way and I treat flakes as primarily as mechanism for
purifying evaluation and caching instantiation, as outlined in this
post:
… and if you view flakes in that capacity then they are a feature of the Nix language since evaluation/instantiation are the primary purpose of the programming language.
Layer #2: The Nix build tool
This layer encompasses the command-line interface to both the “Nix store” and the “Nix language”.
This includes (but is not limited to):
nix-store(the command, not the underlying store)nix-instantiatenix-buildnix-shellnixsubcommands, including:nix buildnix runnix developnix lognix flake
I make this distinction because the command-line interface enables
some additional niceties that are not inherent to the underlying layers.
For example, the nix build command has some flake
integration so that you can say
nix build someFlake#somePackage and this command-line API
nicety is not necessarily inherent to flakes (in my view).
Also, many of these commands operate at both Layer 0 and Layer 1,
which can blur the distinction between the two. For example the
nix-build command can accept a layer 1 Nix program (i.e. a
.nix file) or a layer 0 derivation (i.e. a
.drv file).
Another thing that blurs the distinction is that the Nix manual covers all three of the layers introduced so far, ranging from the Nix store to the command-line interface. However, if you want to better understand these three layers then that is correct place to begin:
Layer #3: Nixpkgs
Nixpkgs is a software distribution (a.k.a. “distro”) for Nix. Specifically, all of the packaging logic for Nixpkgs is hosted on GitHub here:
This repository contains a large number of Nix expressions for building packages across several platforms. If the “Nix language” is a programming language then “Nixpkgs” is a gigantic “library” authored within that language. There are other Nix “libraries” outside of Nixpkgs but Nixpkgs is the one you will interact with the most.
The Nixpkgs repository establishes several widespread idioms and conventions, including:
- The standard environment (a.k.a.
stdenv) for authoring a package- There are also language-specific standard-environments, too
- A domain-specific language for overriding individual packages or sets of packages
When people complain about “Nix’s syntax”, most of the time they’re actually complaining about Nixpkgs and more specifically complaining about the Nixpkgs system for overriding packages. However, I can see how people might mistake the two.
The reason for the confusion is that the Nixpkgs support for overrides is essentially an embedded domain-specific language, meaning that you still express everything in the Nix language (layer 1), but the ways in which you express things is fundamentally different than if you were simply using low-level Nix language features.
As a contrived example, this “layer 1” Nix code:
let
x = 1;
y = x + 2;… would roughly correspond to the following “layer 3” Nixpkgs overlay:
self: super: {
x = 1;
y = self.x + 2;
}The reason why Nixpkgs doesn’t do the simpler “layer 1” thing is because Nixpkgs is designed to support “late binding” of expressions, meaning that everything can be overridden, even dependencies deep within the dependency tree. Moreover, this overriding is done in such a way that everything “downstream” of the overrride (i.e. all reverse dependencies) pick up the change correctly.
As a more realistic example, the following program:
let
pkgs = import <nixpkgs> { };
fast-tags =
pkgs.haskell.lib.justStaticExecutables pkgs.haskellPackages.fast-tags;
fast-tags-no-tests =
pkgs.haskell.lib.dontCheck fast-tags;
in
fast-tags-no-tests… is simpler, but is not an idiomatic use of Nixpkgs because it is not using the overlay system and therefore does not support late binding. The more idiomatic analog would be:
let
overlay = self: super: {
fast-tags =
self.haskell.lib.justStaticExecutables self.haskellPackages.fast-tags;
fast-tags-no-tests =
self.haskell.lib.dontCheck self.fast-tags;
};
pkgs = import <nixpkgs> { overlays = [ overlay ]; };
in
pkgs.fast-tags-no-testsYou can learn more about this abstraction layer by consulting the Nixpkgs manual:
Layer #4: NixOS
NixOS is an operating system that is (literally) built on
Nixpkgs. Specifically, there is a ./nixos/ subdirectory of
the Nixpkgs repository for all of the NixOS-related logic.
NixOS is based on the NixOS module system, which is yet another embedded domain-specific language. In other words, you configure NixOS with Nix code, but the idioms of that Nix code depart even more wildly from straightforward “layer 1” Nix code.
NixOS modules were designed to look more like Terraform modules than
Nix code, but they are still technically Nix code. For example, this is
what the NixOS module for the lorri service looks like at
the time of this writing:
{ config, lib, pkgs, ... }:
let
cfg = config.services.lorri;
socketPath = "lorri/daemon.socket";
in {
options = {
services.lorri = {
enable = lib.mkOption {
default = false;
type = lib.types.bool;
description = lib.mdDoc ''
Enables the daemon for `lorri`, a nix-shell replacement for project
development. The socket-activated daemon starts on the first request
issued by the `lorri` command.
'';
};
package = lib.mkOption {
default = pkgs.lorri;
type = lib.types.package;
description = lib.mdDoc ''
The lorri package to use.
'';
defaultText = lib.literalExpression "pkgs.lorri";
};
};
};
config = lib.mkIf cfg.enable {
systemd.user.sockets.lorri = {
description = "Socket for Lorri Daemon";
wantedBy = [ "sockets.target" ];
socketConfig = {
ListenStream = "%t/${socketPath}";
RuntimeDirectory = "lorri";
};
};
systemd.user.services.lorri = {
description = "Lorri Daemon";
requires = [ "lorri.socket" ];
after = [ "lorri.socket" ];
path = with pkgs; [ config.nix.package git gnutar gzip ];
serviceConfig = {
ExecStart = "${cfg.package}/bin/lorri daemon";
PrivateTmp = true;
ProtectSystem = "strict";
ProtectHome = "read-only";
Restart = "on-failure";
};
};
environment.systemPackages = [ cfg.package ];
};
}You might wonder how NixOS relates to the underlying layers. For example, if Nix is a build system, then how do you “build” NixOS? I have another post which elaborates on that subject here:
Also, you can learn more about this abstraction layer by consulting the NixOS manual:
Nix ecosystem
I use the term “Nix ecosystem” to describe all of the preceding
layers and other stuff not mentioned so far (like hydra,
the continuous integration service).
This is not a layer of its own, but I mention this because I prefer to use “Nix ecosystem” instead of “Nix” to avoid ambiguity, since the latter can easily be mistaken for an individual abstraction layer (especially the Nix language or the Nix build tool).
However, when I do hear people say “Nix”, then I generally understand it to mean the “Nix ecosystem” unless they clarify otherwise.
Conclusion
Hopefully this passive aggressive post helps people express themselves a little more precisely when discussing the Nix ecosystem.
If you enjoy this post, you will probably also like this other post of mine:
… since that touches on the Nixpkgs and NixOS embedded domain-specific languages and how they confound the user experience.
I’ll conclude this post with the following obligatory joke:
I’d just like to interject for a moment. What you’re refering to as Nix, is in fact, NixOS, or as I’ve recently taken to calling it, Nix plus OS. Nix is not an operating system unto itself, but rather another free component of a fully functioning ecosystem made useful by the Nix store, Nix language, and Nix build tool comprising a full OS as defined by POSIX.
Many Guix users run a modified version of the Nix ecosystem every day, without realizing it. Through a peculiar turn of events, the operating system based on Nix which is widely used today is often called Nix, and many of its users are not aware that it is basically the Nix ecosystem, developed by the NixOS foundation.
There really is a Nix, and these people are using it, but it is just a part of the system they use. Nix is the expression language: the program in the system that specifies the services and programs that you want to build and run. The language is an essential part of the operating system, but useless by itself; it can only function in the context of a complete operating system. Nix is normally used in combination with an operating system: the whole system is basically an operating system with Nix added, or NixOS. All the so-called Nix distributions are really distributions of NixOS!