Varför ser Nix-sökvägar så konstiga ut?

Om du har kikat in i /nix/store har du säkert sett dem. De där kryptiska mappnamnen som verkar ha gått genom en hash-blender:

/nix/store/s0psayl7zvkvwdcqc8fy1sbv8rlf1yq8-bash-5.3p9

Delen till höger om bindestrecket förstår du direkt — bash-5.3p9 säger exakt vad som finns där. Men de 32 tecknen till vänster? Det är där magin (eller förvirringen) bor.

De flesta förklaringar du hittar är halva sanningen.

Det alla säger — och varför det inte räcker

"Hasen kommer från indata" är det vanliga svaret. Det är inte fel, men det saknas nyans. Den riktiga frågan är: vilka indata? Source-koden du skrev? Byggreceptet? Byggresultatet? Beroendena?

Svaret är: det beror på.

Två namnstrategier i samma mapp

Nix använder faktiskt två helt olika strategier för att döpa saker i store, och de fungerar tillsammans utan problem. Att blanda ihop dem är grunden till all förvirring.

Input-addresserade: Namnet före bygget

För de flesta paket kör Nix ungefär som en arkitekt som granskar ritningar. När du skriver en .nix-expression evaluerar Nix den till en derivation — en konkret specifikation av vad som ska byggas, inklusive:

• Byggskriptet
• Byggargument
• Miljövariabler
• Deklarerade outputs
• Beroenden

Med det här receptet kan Nix räkna ut en unik identitet innan bygget ens startar. De färdiga binärerna finns inte än, men Nix vet redan vad de ska heta.

Det är därför som att redigera en Nix-expression inte alltid ändrar sökvägen. Om dina ändringar inte påverkar det underliggande byggreceptet får du samma identitet. Två olika expressions kan evalueras till identiska recept och dela samma sökväg. Nix dömer bygget, inte din kod.

Content-addresserade: Namnet från bytes

Nix kan också döpa saker direkt från deras innehåll. När du kör nix store add ger du Nix något som redan finns, och det hash-ar bytes direkt. Ingen evaluering, inget recept — bara innehåll.

Här avgörs sökvägen av vad som faktiskt finns i filen. Ändra en enda byte, och hashen ändras.

Varför spelar det roll?

Att förstå de två strategierna gör flera Nix-beteenden plötsligt logiska:

Förutsäga sökvägsändringar. Frågar du dig "kommer den här ändringen påverka sökvägen?" — fråga dig själv: ändrar det byggreceptet eller det faktiska innehållet? Redigera en kommentar i en Nix-expression? Antagligen ingen ny sökväg. Ändra en beroendeversion? Ny sökväg garanterad.

Förstå parallella byggen. Varför kan ett gammalt byggresultat ligga bredvid ett nytt i store? För att de har olika identiteter. Nix skriver inte över — det behöver helt enkelt inte.

Cache-återanvändning fungerar. En binary cache kan tryggt servera en förbyggd sökväg eftersom namnet unikt identifierar byggindata. Samma namn betyder samma innehåll, garanterat.

Mer än bara ett namn

En store-sökväg är aldrig ensam. Byggda paket refererar till andra store-sökvägar (dynamiska bibliotek, interpretatorer, delade resurser), och Nix håller koll på dessa relationer som en graf.

Det här är inte bara metadata — det är en komplett beroendekarta. Från vilken sökväg som helst kan du spåra dess closure: allt som måste följa med för att det ska fungera på en annan maskin. Så här fungerar nix-copy-closure, och varför Nix-deployments är pålitliga.

Samma databas låter Nix verifiera integritet. Det kan kontrollera om bytes på disk fortfarande matchar vad som recordades när sökvägen skapades. Store-sökvägar är inte ogenomskinliga mappnamn — de är frågbara identiteter med full spårbarhet.

Sammanfattning

De kryptiska hasharna är inte slumpmässiga. De är resultatet av ett medvetet designval: Nix dömer derivationer efter indata och innehåll efter bytes. Den dubbla strategin är vad som gör Nix reproducerbart, verifierbart och förvånansvärt förutsägbart när man väl förstår det.

Så nästa gång du ser en store-sökväg — panik inte. Läs från höger till vänster, det är den mänskliga delen. Hashen till vänster är Nix sätt att hålla ett löfte: detta namn betyder detta bygge, och inget annat.

Vill du grotta djupare? Oavsett om du deployar containrar, hanterar infrastruktur eller bara är nyfiken på reproducerbara byggen — att förstå systemets innandöme lönar sig alltid. På NameOcean tror vi att de bästa utvecklarna är de som förstår vad som faktiskt händer under huven, inte bara vilka kommandon man kör.

Happy building.