Was ist Nix?

Deklarativ & reproduzierbar – und deine erste Shell mit einem Tool, das du gar nicht installiert hast.

Das Problem, das Nix löst

Jedes Projekt-README kennt den Abschnitt „Voraussetzungen": installiere Node 20, Postgres 15, ein bestimmtes CLI, setze diese Umgebungsvariable…. Auf deiner Maschine läuft es, bei der neuen Kollegin nicht, in der CI wieder anders. Das ist imperatives Setup: eine Abfolge von Schritten, deren Ergebnis von deinem Rechner abhängt.

Nix dreht das um. Du beschreibst die gewünschte Umgebung in einer Datei – welche Tools, welche Versionen – und Nix stellt genau diese Umgebung her. Bit-genau gleich, auf jeder Maschine. Das ist deklarativ und reproduzierbar.

Unser durchgehendes Beispiel

Statt „Hello World" begleitet uns durch den Kurs eine kleine, realistische Aufgabe: eine geteilte Dev-Umgebung für ein Projekt namens „toolbox". Wir bauen sie Lektion für Lektion aus – am Ende mit eigener flake.nix, einer mkShell-Umgebung, gepinnter flake.lock und einem selbst gebauten CLI-Tool:

toolbox/
├── flake.nix      # ← beschreibt Dev-Shell + eigene Pakete (ab Lektion 5)
├── flake.lock     # ← pinnt alles exakt (Lektion 8)
└── src/           # der eigentliche Projekt-Code

Heute fangen wir ganz vorne an: Wir holen uns ein Tool in eine Shell, ohne es zu installieren.

Die vier Begriffe

Vier Bausteine erklären, wie Nix denkt. Mehr brauchst du fürs Erste nicht:

• Nix – das Tool, das Nix-Beschreibungen auswertet und baut. (Auch der Name der Sprache.)
• Nixpkgs – die riesige Sammlung fertiger Paket-Beschreibungen, aus der du Tools ziehst.
• Derivation – die exakte Bau-Anweisung für genau ein Ergebnis (ein Tool, eine Shell).
• Store – /nix/store, wo jedes Ergebnis unter einem Hash-Pfad landet.

Der rote Faden: Eine Nix-Datei wird zu einer Derivation ausgewertet; Nix realisiert sie dann in den Store. Weil der Store-Pfad ein Hash über alle Inputs ist, ergeben gleiche Inputs garantiert dasselbe Ergebnis – das ist die ganze Magie der Reproduzierbarkeit.

Deine erste Nix-Shell

Genug Theorie. Angenommen, du brauchst kurz das Tool cowsay, hast es aber nicht installiert. Mit Nix holst du es dir in eine temporäre Shell – ohne dein System zu verändern:

# holt cowsay aus nixpkgs in eine neue Shell
$ nix shell nixpkgs#cowsay

# jetzt ist cowsay verfügbar – nur in dieser Shell
$ cowsay "Reproduzierbar!"

# Shell verlassen – cowsay ist wieder weg, System unverändert
$ exit

Was hier passiert

• nix shell startet eine neue Shell, in der die genannten Pakete im PATH liegen.
• nixpkgs#cowsay heißt: nimm das Attribut cowsay aus der Sammlung nixpkgs. Das # trennt die Quelle vom Attribut.
• Nix lädt (oder baut) cowsay in den Store und verlinkt es in deine Shell – nicht in /usr/bin. Dein System bleibt sauber.
• Nach exit ist alles weg. Der Store-Eintrag bleibt im Cache, der nächste Aufruf ist sofort da.

Klassisch vs. modern

Dir werden draußen zwei Schreibweisen begegnen. Wir gehen den modernen Weg (Flakes), weil er Lock-Files mitbringt – dein erklärtes Lernziel. Zum Wiedererkennen:

# modern (Flakes) – dieser Kurs:
$ nix shell nixpkgs#cowsay

# klassisch (du wirst es in alten Anleitungen sehen):
$ nix-shell -p cowsay

Besonderheiten & Stolperfallen

Kurz prüfen (aus dem Kopf)

Nicht spicken – Abrufen aus dem Gedächtnis ist genau die Übung, die hängen bleibt.

$ nix shell nixpkgs#cowsay nixpkgs#lolcat
$ cowsay "hi" | lolcat
$ which cowsay
# → /nix/store/xxxx…-cowsay-3.04/bin/cowsay  (im Store, nicht /usr/bin!)
$ exit
$ which cowsay
# → cowsay not found  (System war nie verändert)