Die Shell betritt sich von selbst – und tut das schnell. Der Komfort, der Nix im Alltag tragbar macht.
cd in ein Projekt – und die Dev-Shell ist
einfach da, in deiner gewohnten Shell, ohne nix develop zu tippen. Mit Caching wird das
auch noch sofort schnell. Das verwandelt Nix von „mächtig, aber umständlich" in „mächtig und bequem".
nix develop ist toll, aber: Du musst es tippen, es wirft dich in eine nackte
bash (Lektion 6), und beim Projektwechsel vergisst man es. direnv
betritt & verlässt die Umgebung automatisch, sobald du das Verzeichnis betrittst
oder verlässt – in deiner eigenen Shell.
# 1) direnv + nix-direnv installieren (z.B. via Home-Manager oder nix profile)
# und den direnv-Hook in deine ~/.zshrc / ~/.config/fish einbinden.
# 2) Im Projekt eine .envrc anlegen:
$ echo "use flake" > .envrc
# 3) einmal freischalten (Sicherheits-Opt-in):
$ direnv allow
Ab jetzt gilt: cd toolbox/ → Shell ist aktiv (Tools, env vars, shellHook aus Lektion 7).
cd .. → alles wieder weg. Du tippst nie wieder nix develop.
use flake vs. use nix
use flake lädt devShells.default aus deiner flake.nix – unser Weg.
use nix ist das Pendant für ein klassisches shell.nix. Beide kommen von
nix-direnv.
nix-direnv?
Reines direnv würde die Umgebung bei jedem cd neu auswerten – spürbar langsam.
nix-direnv cached das Ergebnis und hält es als
GC-Root (Lektion 13: schützt vor Garbage Collection). Resultat: Der erste Eintritt baut/lädt,
jeder weitere ist praktisch instant.
Ein zweiter Beschleuniger, der schon ab Lektion 1 still mitläuft: Binary Caches. Statt
jedes Paket lokal zu kompilieren, lädt Nix vorgebaute Ergebnisse aus
cache.nixos.org (dem offiziellen Substituter). Deshalb ging
nix shell nixpkgs#cowsay in Sekunden statt Minuten.
# eigene/teamweite Caches ergänzt man als zusätzliche substituters:
$ nix develop --option substituters \
"https://cache.nixos.org https://dein-team.cachix.org"Für Teams baut man eigene Pakete einmal in der CI und lädt sie über einen Cache (z. B. Cachix) zu allen – niemand baut die toolbox-CLI doppelt.
.envrc braucht direnv allow
Aus Sicherheit führt direnv eine neue oder geänderte .envrc erst nach
direnv allow aus. „direnv: error .envrc is blocked" heißt schlicht: einmal erlauben.
.direnv/ ins .gitignore
nix-direnv legt einen lokalen Cache-Ordner .direnv/ an. Der gehört
nicht ins Repo – aber die .envrc schon (sie ist Teil der geteilten
Umgebung).
nix-direnv ist es langsam
Reines direnv + use flake funktioniert, cached aber nicht und hält keinen
GC-Root. Installier nix-direnv – ohne den fehlt der halbe Nutzen.
Nicht spicken – Abrufen aus dem Gedächtnis ist genau die Übung, die hängen bleibt.
Was bewirkt eine .envrc mit use flake?
use flake lädt devShells.default automatisch, sobald du das Verzeichnis
betrittst – kein nix develop mehr nötig.
Wozu dient nix-direnv gegenüber reinem direnv?
nix-direnv macht den Eintritt schnell (Cache) und schützt die Umgebung vor der
Garbage Collection (GC-Root, Lektion 13).
Warum ging nix shell nixpkgs#cowsay in Sekunden?
cache.nixos.org liefert vorgebaute Ergebnisse (Substituter). Ohne diesen Cache müsste
Nix jedes Paket lokal bauen.
Ziel: Die toolbox-Shell per direnv automatisch betreten.
direnv + nix-direnv installiert und der Hook aktiv ist.echo "use flake" > .envrc an und führe direnv allow aus.shellHook-Gruß?.direnv/ in der .gitignore, committe die .envrc.Tipp: direnv reload erzwingt ein erneutes Laden, ohne den Ordner zu wechseln.
$ echo "use flake" > .envrc
$ direnv allow
# direnv: loading .envrc
# → toolbox bereit (dein shellHook aus Lektion 7)
$ echo ".direnv/" >> .gitignore
$ git add .envrc .gitignoreAb jetzt ist die richtige Umgebung in jedem Projekt automatisch da.
use flake, Caching und GC-Roots. Kurz, praxisnah, aktuell.
fish-Config?
Sag mir deine Shell – ich gebe dir die exakte Hook-Zeile.