Nixpkgs & `pkgs`

Woher die Pakete kommen – und wie du das richtige findest und referenzierst.

Warum das zählt
Deine Dev-Shell ist eine Liste von Paketen. Diese Pakete kommen aus Nixpkgs. Heute lernst du, was pkgs wirklich ist (ein riesiges Attribute-Set), wie du Pakete suchst und wie du sie referenzierst – die letzte Zutat vor Flakes & mkShell.

Nixpkgs ist nur ein großes Set

Nixpkgs ist ein Git-Repo voller Paket-Definitionen. Wird es ausgewertet, entsteht daraus ein gigantisches Attribute-Set – per Konvention pkgs genannt. Jedes Paket ist ein Attribut darin:

pkgs.git
pkgs.ripgrep
pkgs.python3
pkgs.nodejs_22
pkgs.go

Das ist exakt der Attribut-Zugriff mit Punkt aus Lektion 3 – nur auf einem sehr großen Set. Es gibt auch geschachtelte Gruppen, z. B. pkgs.python3Packages.requests.

`pkgs` im `nix repl` erkunden

$ nix repl
nix-repl> :lf nixpkgs        # lädt das nixpkgs-Flake; pkgs etc. verfügbar
nix-repl> legacyPackages.x86_64-linux.ripgrep
«derivation /nix/store/…-ripgrep-14.1.0.drv»
nix-repl> legacyPackages.x86_64-linux.ripgrep.version
"14.1.0"

Jedes Paket ist eine Derivation (Lektion 1) mit Metadaten wie .version, .meta.description und dem Ergebnis-Pfad im Store.

Pakete finden

Drei Wege, das richtige Attribut zu finden – vom bequemsten zum mächtigsten:

search.nixos.org – die Web-Suche. Zeigt Attributnamen, Versionen, Beschreibung. Erste Anlaufstelle.
nix search nixpkgs begriff – dasselbe auf der Kommandozeile.
nix repl + Tab-Completion auf pkgs. – zum Stöbern.

$ nix search nixpkgs ripgrep
# * legacyPackages.x86_64-linux.ripgrep (14.1.0)
#   A utility that combines the usability of The Silver Searcher…

Attributname ≠ Programmname Das Attribut heißt nicht immer wie der Befehl. Beispiel: das Attribut pkgs.ripgrep liefert den Befehl rg. Such immer nach dem Attributnamen – den brauchst du in der Dev-Shell, nicht den Befehlsnamen.

`pkgs.lib`: die Werkzeugkiste

Neben Paketen enthält pkgs auch pkgs.lib – Hilfsfunktionen, die du in Dev-Shells oft brauchst, etwa um plattformabhängig Pakete anzuhängen:

# nur unter Linux zusätzlich inotify-tools mitnehmen
packages = [ pkgs.git ]
  ++ pkgs.lib.optionals pkgs.stdenv.isLinux [ pkgs.inotify-tools ];

Dein Win Du hast jetzt alle Zutaten beisammen: Sprache (L2–3) und die Paketquelle (L4). Ab der nächsten Lektion gießen wir das in eine flake.nix und bauen die erste echte Dev-Shell.

Besonderheiten & Stolperfallen

Versionen nicht frei wählbar Du bekommst die Version, die dein Nixpkgs mitbringt. „Ich will genau Node 18.17.1" löst man nicht mit einem Versionsfeld, sondern indem man Nixpkgs auf den passenden Stand pinnt – genau dafür gibt es Lock-Files (Lektion 8).

Unfreie Pakete sind blockiert Manche Pakete (z. B. vscode, einige Treiber) sind „unfree" und werden ohne allowUnfree in der Nixpkgs-Konfiguration abgelehnt. Die Fehlermeldung sagt dir das klar.

Mehrere Versionen nebeneinander Für gängige Sprachen gibt es versionierte Attribute: nodejs_20, nodejs_22, python311, python312. So bestimmst du grob die Major-Version direkt im Namen.

Kurz prüfen (aus dem Kopf)

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

Was ist pkgs aus Sicht der Nix-Sprache?

Ein sehr großes Attribute-Set mit Paketen
Ein Ordner mit fertigen Binärdateien
Ein Befehl, der Pakete herunterlädt

Nixpkgs wird zu einem riesigen Attribute-Set ausgewertet; pkgs.git ist nur ein Attributzugriff darauf. Genau das Set-Wissen aus Lektion 3.

Wo findest du am schnellsten den richtigen Attributnamen?

Über die Suche auf search.nixos.org
Indem du den Programmnamen einfach rätst
In der README des jeweiligen Projekts

search.nixos.org (oder nix search) zeigt den exakten Attributnamen, der oft vom Befehlsnamen abweicht (ripgrep → rg). Raten führt in die Irre.

Wie legst du fest, welche Version ein Paket hat?

Indem du das Nixpkgs auf einen Stand pinnst
Indem du ein Versionsfeld am Paket setzt
Indem du stets das neueste Release lädst

Übung für Teilnehmende

Ziel: Drei Pakete für die toolbox-Shell finden und ihre Versionen prüfen.

Suche auf search.nixos.org nach jq, fd und go.
Notiere die exakten Attributnamen (nicht die Befehlsnamen).
Lass dir per nix search nixpkgs fd die Version auf der CLI anzeigen.
Bonus: Finde heraus, welchen Befehl das Attribut fd bereitstellt.

Tipp: Auf der Suchseite steht „Provided programs" – dort siehst du die echten Befehle.

Lösung anzeigen

# Attributnamen: jq, fd, go  (hier gleich dem Befehl, oft aber nicht)
$ nix search nixpkgs fd
# * legacyPackages.x86_64-linux.fd (10.x)
#   A simple, fast and user-friendly alternative to find
# Bereitgestellter Befehl: fd

Diese drei Attributnamen wandern gleich in deine erste mkShell-Paketliste.

Primärquelle zum Lesen search.nixos.org – Package search. Kein Fließtext, aber dein wichtigstes tägliches Werkzeug. Such drei Tools, die du selbst nutzt, und präg dir die Attributnamen ein.

Ich bin dein Teacher. Du findest ein Tool nicht, oder ein Paket ist „unfree"? Sag mir, welches – ich zeige dir den Attributnamen und den sauberen Weg, es freizuschalten.

← Lektion 3 · Sets & Funktionen Lektion 5 · Flakes-Grundlagen →

Als Nächstes: Lektion 5 – Flakes-Grundlagen (flake.nix: inputs/outputs)

Nixpkgs & pkgs

Nixpkgs ist nur ein großes Set

pkgs im nix repl erkunden

Pakete finden

pkgs.lib: die Werkzeugkiste

Besonderheiten & Stolperfallen

Kurz prüfen (aus dem Kopf)

Nixpkgs & `pkgs`

`pkgs` im `nix repl` erkunden

`pkgs.lib`: die Werkzeugkiste