Tajemství Nix store paths odhaleno

Určitě jste je viděli. Ty zastrašující názvy adresářů v /nix/store, které vypadají, jako by někdo prohnál název balíčku šifrovacím mlýnkem na maso:

/nix/store/s0psayl7zvkvwdcqc8fy1sbv8rlf1yq8-bash-5.3p9

Část s lidsky čitelným názvem je jasná — bash-5.3p9 vám přesně říká, co je uvnitř. Ale těch 32 znaků před pomlčkou? Tam se skrývá ta záhada. A tady je pointa: většina vysvětlení, která potkáte, je neúplná.

Rozšířené (a špatné) vysvětlení

„Hash pochází ze vstupů" — to vám řekne většina lidí. Nemají úplně pravdu, ale chybí jim důležitý detail. Ta pravá otázka zní: jaké vstupy? Hashujeme zdrojové soubory, které jste napsali? Build recept, který Nix vygeneruje? Bajty vzniklé buildu? Závislosti?

Upřímná odpověď zní: záleží na situaci.

Dvě schémata pojmenování, jeden adresář

Nix ve skutečnosti používá dvě různé mechanismy pojmenování store cest, a obě spokojeně koexistují pod /nix/store. Směšování těchto dvou přístupů — to je, kde začíná celý zmatek.

Input-addressed: Jména předem, podle receptu

U většiny buildů balíčků Nix funguje jako architekt kontrolující plány. Když napíšete .nix výraz, Nix ho vyhodnotí do podoby derivation — konkrétní specifikace toho, co se má postavit, včetně:

• Builder skriptu
• Build argumentů
• Proměnných prostředí
• Deklarovaných výstupů
• Závislostí

S tímto receptem v ruce dokáže Nix spočítat unikátní identifikátor ještě před tím, než se build vůbec spustí. Hotové binárky ještě neexistují, ale Nix už ví, jak je pojmenovat.

Proto editace Nix výrazu ne vždy změní store path. Pokud vaše změny neovlivňují samotný build recept, Nix vyprodukuje stejný identifikátor. Dva různé výrazy se můžou vyhodnotit na identické recepty, takže sdílejí stejnou store path. Nix pojmenovává to, co bude stavět — ne styl vašeho kódu.

Content-addressed: Jména podle obsahu

Nix ale taky umí pojmenovat store objekty přímo podle jejich obsahu. Když spustíte nix store add, předáte Nixu něco, co už existuje, a on okamžitě zahashuje bajty. Žádné vyhodnocování, žádný recept — jen obsah.

Tady je cesta určena tím, co je skutečně v souboru. Změníte jediný bajt, a hash se změní.

Proč je toto rozlišení důležité

Pochopení těchto dvou schémat pojmenování náhle objasní spoustu Nix chování:

Předvídání změn cest. Ptáte se „ovlivní editace X store path?" Zeptejte se sami sebe: mění X build recept nebo skutečný obsah? Upravíte komentář v Nix výrazu? Pravděpodobně žádná nová cesta. Změníte verzi závislosti? Nová cesta zaručena.

Sousedící buildy dávají smysl. Proč může starý výsledek buildu sedět vedle nového v store? Protože mají různé identity. Nix nepřepisuje — prostě nemá důvod.

Znovupoužití cache也开始 být logické. Binary cache může s jistotou servírovat předpřipravenou cestu, protože název jednoznačně identifikuje build vstupy. Stejný název znamená stejný obsah, garantováno.

Více než jen jméno

Store path nikdy není opravdu sám. Postavené balíčky odkazují na další store paths (dynamické knihovny, interpretry, sdílená aktiva), a Nix sleduje tyto vztahy jako graf.

Nejde jen o metadata — je to kompletní mapa závislostí. Z jakékoli cesty můžete vysledovat její closure: vše, co s ní musí cestovat, aby fungovala na jiném stroji. Tak funguje nix-copy-closure, a proč jsou Nix deploymenty spolehlivé.

Stejná databáze umožňuje Nix ověřit integritu. Může zkontrolovat, jestli bajty na disku stále odpovídají tomu, co zaznamenal při vytvoření cesty. Store paths nejsou neprůhledné názvy adresářů — jsou to dotazovatelné identity s úplným audit trailem.

Závěr

Ty kryptické hashe nejsou arbitrální. Jsou výsledkem záměrného designového rozhodnutí: Nix pojmenovává derivations podle vstupů a obsah podle bajtů. Tento duální přístup je to, co dělá Nix reprodukovatelným, ověřitelným a překvapivě předvídatelným, jakmile to pochopíte.

Takže příště, když uvidíte store path, nepanikařte. Čtěte zprava doleva — to je ta lidská část. Hash nalevo je jen Nixův způsob, jak dát slib: toto jméno znamená tento build, a nic jiného.

Chcete proniknout hlouběji? Ať už nasazujete kontejnery, spravujete infrastrukturu, nebo vás jen zajímají reprodukovatelné buildy, pochopení vnitřního fungování systému se vždy vyplatí. V NameOcean věříme, že nejlepší vývojáři jsou ti, kteří rozumí tomu, co se skutečně děje pod kapotou — ne jen které příkazy psát.

Šťastné stavění.