Die Sammlung an Wissen, die im Workshop die „Aber was, wenn…?"-Fragen beantwortet.
nix develop vs. nix-shellZwei Generationen für dasselbe Ziel. Du erkennst beide draußen:
| modern (Flakes) | klassisch |
|---|---|
flake.nix + flake.lock |
shell.nix (kein Lock) |
nix develop |
nix-shell |
| gepinnt & teilbar by default | pinnen nur manuell (z. B. niv) |
Unser Kurs nutzt den modernen Weg – wegen der Lock-Files, deinem Lernziel. Beide bauen auf mkShell.
nix develop ist pure: Es blendet die meisten Variablen deines Systems aus,
damit die Umgebung überall gleich ist. Manchmal brauchst du aber etwas von außen (eine
System-Variable, einen lokalen Pfad):
$ nix develop --impure # lässt das System-Environment durch--impure ist ein Notausgang
Es bricht bewusst die Reproduzierbarkeit auf. Sparsam einsetzen und dokumentieren – sonst läuft es
„bei dir", weil deine Maschine etwas mitbringt, das anderen fehlt.
Der Store wächst. nix-collect-garbage löscht alles, was nicht erreichbar ist.
Erreichbar = von einem GC-Root referenziert. Was du wissen musst:
./result (von nix build) ist ein GC-Root – dein Build bleibt erhalten.nix-direnv (Lektion 12) legt einen GC-Root an – deine aktive Dev-Shell wird nicht weggeräumt.nix-collect-garbage beim nächsten Eintritt neu bauen.$ nix-collect-garbage # räumt unerreichbare Store-Pfade weg
$ nix-collect-garbage -d # zusätzlich alte Profil-Generationen
Vertiefung aus Lektion 12: cache.nixos.org ist der Default-Substituter. Eigene Caches
(Cachix, attic) ergänzt man projekt- oder systemweit. Faustregel: Selbst gebaute Pakete in
der CI einmal bauen und in einen Team-Cache pushen – dann lädt jede:r nur noch.
mkShell
bauen, sie über flake.lock pinnen, ein eigenes Paket bauen und einbinden, und das Ganze
per direnv bequem machen. Das ist exakt die Mission – erfüllt. Jetzt kannst du es unterrichten.
Nicht spicken – Abrufen aus dem Gedächtnis ist genau die Übung, die hängen bleibt.
Was bedeutet „nix develop ist pure"?
Pure heißt: möglichst unabhängig von deiner Maschine, damit die Umgebung überall gleich ist.
--impure öffnet diesen Schutz gezielt.
Warum überlebt deine aktive Dev-Shell ein nix-collect-garbage?
Die GC löscht nur Unerreichbares. Ein GC-Root (von nix-direnv oder ./result)
macht die Umgebung erreichbar – sie bleibt erhalten.
Welcher Weg pinnt Versionen von Haus aus?
Flakes bringen die flake.lock automatisch mit. Klassische shell.nix pinnt
man nur mit Zusatzwerkzeugen – genau deshalb ist Flakes hier der Hauptweg.
Ziel: Eine produktionsreife flake.nix, die alles aus dem Kurs vereint.
nixos-24.11) und committe die flake.lock.mkShell mit Tools, einer env var und einem Begrüßungs-shellHook.toolbox.nix-Paket per callPackage als packages.default ein und nimm es in die Shell auf..envrc mit use flake an und teste den automatischen Eintritt.Das ist die Vorlage, die du im Workshop austeilen kannst – sie zeigt jedes Konzept des Kurses an einem Stück.
{
description = "toolbox dev environment";
inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-24.11";
outputs = { self, nixpkgs }:
let
system = "x86_64-linux";
pkgs = nixpkgs.legacyPackages.${system};
toolbox = pkgs.callPackage ./toolbox.nix {};
in {
packages.${system}.default = toolbox;
devShells.${system}.default = pkgs.mkShell {
packages = [ pkgs.go pkgs.jq toolbox ];
PROJECT = "toolbox";
shellHook = ''echo "→ $PROJECT bereit"'';
};
};
}
# + echo "use flake" > .envrc && direnv allowSprache, Flake, Lock, mkShell, eigenes Paket, direnv – alles in einer Datei. Das ist deine Mission, fertig.
flake.nix gemeinsam und gehen die kniffligen
Stellen durch.