Die geheime Sprache der Nix Store-Pfade

Du kennst diese kryptischen Verzeichnisnamen in /nix/store. Sie sehen aus, als hätte jemand einen Paketnamen durch einen Hash-Algorithmus gejagt:

/nix/store/s0psayl7zvkvwdcqc8fy1sbv8rlf1yq8-bash-5.3p9

Der lesbare Teil ist klar – bash-5.3p9 verrät sofort, was drin steckt. Aber diese 32 Zeichen vor dem Bindestrich? Da passiert das Magische. Und ehrlich gesagt: Die meisten Erklärungen, die du findest, erzählen nur die halbe Wahrheit.

Die gängige (aber falsche) Erklärung

„Der Hash kommt von den Inputs" – so lautet die Standardantwort. Sie ist nicht völlig falsch, aber sie lässt entscheidende Nuancen unter den Tisch fallen. Die richtige Frage ist nämlich: welche Inputs? Hashen wir die Source-Dateien? Das Build-Rezept? Die resultierenden Bytes? Die Abhängigkeiten?

Die ehrliche Antwort: Es kommt darauf an.

Zwei Namensschemen, ein Verzeichnis

Nix nutzt tatsächlich zwei verschiedene Mechanismen für Store-Pfade – und beide koexistieren fröhlich in /nix/store. Wer beides vermischt, versteht nichts.

Input-Addressed: Der Name entsteht vor dem Build

Bei den meisten Paket-Builds funktioniert Nix wie ein Architekt, der Baupläne prüft. Wenn du eine .nix-Expression schreibst, wertet Nix sie zu einer Derivation aus – einem konkreten Bauplan, der enthält:

• Das Builder-Script
• Build-Argumente
• Umgebungsvariablen
• Deklarierte Outputs
• Abhängigkeiten

Mit diesem Rezept kann Nix eine eindeutige Kennung berechnen, bevor der Build überhaupt läuft. Die fertigen Binaries existieren noch nicht, aber Nix weiß bereits, wie es sie nennen wird.

Deshalb ändert das Bearbeiten einer Nix-Expression nicht automatisch den Store-Pfad. Solange deine Änderungen den zugrundeliegenden Bauplan nicht beeinflussen, produziert Nix dieselbe Identität. Zwei verschiedene Expressions können zu identischen Rezepten evaluieren – und teilen sich dann denselben Pfad. Nix benennt, was es bauen wird, nicht die Schreibweise deines Codes.

Content-Addressed: Der Name kommt von den Bytes

Nix kann Store-Objekte aber auch direkt über ihren Inhalt benennen. Wenn du nix store add ausführst, übergibst du Nix etwas, das bereits existiert. Es hasht die Bytes sofort. Keine Evaluation, kein Rezept – nur Inhalt.

Hier bestimmt die tatsächliche Datei den Pfad. Änderst du ein einziges Byte, ändert sich der Hash.

Warum dieser Unterschied wichtig ist

Sobald du beide Namensschemen verstehst, werden etliche Nix-Verhaltensweisen plötzlich klar:

Pfadänderungen vorhersagen. Fragst du dich „Beeinflusst das Bearbeiten von X den Store-Pfad?", dann frage dich: Ändert X das Build-Rezept oder den eigentlichen Inhalt? Einen Kommentar in einer Nix-Expression ändern? Wahrscheinlich kein neuer Pfad. Eine Abhängigkeitsversion ändern? Neuer Pfad garantiert.

Koexistierende Builds verstehen. Warum kann ein altes Build-Ergebnis neben einem neuen im Store liegen? Weil sie unterschiedliche Identitäten haben. Nix überschreibt nicht – es muss einfach nicht.

Cache-Wiederverwendung macht Sinn. Ein Binary Cache kann einen vorgebauten Pfad bedenkenlos ausliefern, weil der Name die Build-Inputs eindeutig identifiziert. Gleicher Name bedeutet gleicher Inhalt – garantiert.

Mehr als nur ein Name

Ein Store-Pfad steht nie wirklich allein. Gebaute Pakete referenzieren andere Store-Pfade – dynamische Libraries, Interpreter, geteilte Assets – und Nix verfolgt diese Beziehungen als Graph.

Das ist kein bloßes Metadaten-Geschnörkel. Es ist eine vollständige Abhängigkeitskarte. Von jedem Pfad aus kannst du seine Closure verfolgen: alles, was mit ihm reisen muss, um auf einer anderen Maschine zu funktionieren. So funktioniert nix-copy-closure, und deshalb sind Nix-Deployments zuverlässig.

Dieselbe Datenbank erlaubt Nix die Integritätsprüfung. Es kann verifizieren, ob die Bytes auf der Platte noch mit dem übereinstimmen, was beim Erstellen des Pfads aufgezeichnet wurde. Store-Pfade sind keine undurchsichtigen Verzeichnisnamen – sie sind abfragbare Identitäten mit vollständigem Prüfpfad.

Die Erkenntnis

Diese kryptischen Hashes sind nicht willkürlich. Sie sind das Ergebnis einer bewussten Designentscheidung: Nix benennt Derivationen nach ihren Inputs und Inhalte nach ihren Bytes. Dieser Duale Ansatz macht Nix reproduzierbar, verifizierbar und überraschend vorhersagbar – sobald man ihn versteht.

Also keine Panik, wenn du das nächste Mal einen Store-Pfad siehst. Lies von rechts nach links – das ist der menschliche Teil. Der Hash links ist nichts anderes als Nix' Art, ein Versprechen zu geben: Dieser Name bedeutet diesen Build, und nichts anderes.

Bereit für tieferes Eintauchen? Ob du Container deployst, Infrastruktur verwaltest oder einfach neugierig auf reproduzierbare Builds bist – die Interna deines Systems zu verstehen lohnt sich immer. Bei NameOcean glauben wir, dass die besten Entwickler diejenigen sind, die wirklich begreifen, was unter der Haube passiert – nicht nur, welche Befehle sie tippen müssen.

Viel Spaß beim Bauen.