Nix Store Path'leri: Hash'lerin Arkasındaki Sır

O uzun dizeleri görmüşsünüzdür. /nix/store altında köşeye sinmiş, sanki bir paket ismi şifreleme makinesinden geçirilmiş gibi duran garip klasör isimleri:

/nix/store/s0psayl7zvkvwdcqc8fy1sbv8rlf1yq8-bash-5.3p9

Sağ taraftaki okunabilir kısım (bash-5.3p9) ne olduğunu hemen ele veriyor. Ama o tire işaretinden önceki 32 karakter? İşte bütün sır orada gizli. Ve gerçek şu ki: internette bulacağın açıklamaların çoğu ya eksik ya da yanlış anlaşılmış.

Herkesin Bildiği (Ama Yanlış Olan) Açıklama

Çoğu kişi "hash, girdilerden geliyor" diye açıklıyor. Tamamen yanlış değiller—ama kritik bir noktayı atlıyorlar. Asıl soru şu: hangi girdiler? Yazdığın kaynak dosyalar mı? Nix'in oluşturduğu build tarifi mi? Build sonucu üretilen baytlar mı? Bağımlılıklar mı?

Dürüst cevap: duruma bağlı.

İki İsimlendirme Sistemi, Tek Dizin

Nix aslında store path'leri için iki farklı mekanizma kullanıyor ve ikisi de /nix/store altında huzur içinde bir arada yaşıyor. Karmaşayı başlatan şey, bu ikisini birbirine karıştırmak.

Input-Addressed: Build Öncesi İsimlendirme

Çoğu paket build'i için Nix, mimarın planları incelemesi gibi çalışır. Bir .nix ifadesi yazdığında, Nix onu bir derivation'a—yani neyin inşa edileceğine dair somut bir spesifikasyona—dönüştürür:

• Builder script'i
• Build argümanları
• Ortam değişkenleri
• Beyan edilen çıktılar
• Bağımlılıklar

Elinde bu tarif olduğunda, Nix build çalışmadan önce benzersiz bir tanımlayıcı hesaplayabilir. Bitmiş ikili dosyalar henüz yok, ama Nix onlara nasıl hitap edeceğini çoktan biliyor.

İşte bu yüzden bir Nix ifadesini düzenlemek her zaman store path'i değiştirmiyor. Değişikliklerin temel build tarifini etkilememesi durumunda, Nix aynı tanımlayıcıyı üretir. İki farklı ifade aynı tarife evrilebilir ve dolayısıyla aynı store path'i paylaşabilir. Nix, kodunun nasıl yazıldığına değil, neyi inşa edeceğine isim veriyor.

Content-Addressed: Baytlardan İsimlendirme

Nix, store nesnelerini doğrudan içeriklerinden de isimlendirebilir. nix store add komutunu çalıştırdığında, Nix'e zaten var olan bir şey veriyorsun ve o baytları anında hash'liyor. Değerlendirme yok, tarif yok—sadece içerik.

Burada path, dosyanın içinde ne olduğuyla belirleniyor. Tek bir baytı değiştir, hash değişir.

Bu Ayrım Neden Önemli?

Bu iki isimlendirme sistemini anlamak, Nix'in birçok davranışını aniden aydınlatıyor:

Path değişikliklerini tahmin etmek. "X'i düzenlersem store path değişir mi?" diye merak ediyorsan, kendine şu soruyu sor: X, build tarifini mi yoksa gerçek içeriği mi değiştiriyor? Nix ifadesindeki bir yorumu mı değiştirdin? Büyük ihtimalle yeni path yok. Bağımlılık versiyonunu mu değiştirdin? Yeni path kesin.

Yan yana build'lerin mantığını kavramak. Eski bir build sonucu neden yeni biriyle store'da yan yana durabiliyor? Çünkü farklı kimliklere sahipler. Nix üzerine yazmaz—yazmasına gerek yoktur.

Cache yeniden kullanımı mantıklı hale gelir. Bir binary cache, önceden inşa edilmiş bir path'i güvenle sunabilir çünkü isim, build girdilerini benzersiz şekilde tanımlıyor. Aynı isim, aynı içerik—garanti altında.

Sadece Bir İsim Değil

Bir store path aslında yalnız değil. İnşa edilmiş paketler, diğer store path'leri referans veriyor (dynamic library'ler, interpreter'lar, paylaşılan asset'ler) ve Nix bu ilişkileri bir graph olarak takip ediyor.

Bu sadece meta data değil—tam teşekkürlü bir bağımlılık haritası. Herhangi bir path'ten, closure'ını izleyebilirsin: başka bir makinede çalışması için onunla birlikte taşınması gereken her şey. İşte nix-copy-closure böyle çalışıyor ve Nix deployment'ları neden bu kadar güvenilir.

Aynı veritabanı, Nix'in bütünlüğü doğrulamasına da olanak tanıyor. Diskteki baytların, path oluşturulduğu zaman kaydedilenlerle hâlâ eşleşip eşleşmediğini kontrol edebilir. Store path'ler opak dizin isimleri değil—tam bir denetim izi olan sorgulanabilir kimlikler.

Son Söz

O şifreli hash'ler rastgele değil. Kasıtlı bir tasarım kararının sonucuları: Nix, derivation'ları girdileriyle, içerikleri baytlarıyla isimlendiriyor. Bu ikili yaklaşım, Nix'i tekrarlanabilir, doğrulanabilir ve anladığın zaman şaşırtıcı derecede öngörülebilir kılıyor.

Bir dahaki sefere store path gördüğünde panik yapma. Sağdan sola oku—insan tarafından okunabilir kısım orada. Sol taraftaki hash, Nix'in verdiği bir sözden başka bir şey değil: bu isim bu build'e ait, başka hiçbir şeye değil.

Daha derine inmek ister misin? Container deployment'ları, altyapı yönetimi veya sadece tekrarlanabilir build'ler hakkında merak—sistemizin iç işleyişini anlamak her zaman kendini amorti ediyor. NameOcean'da, kaputun altında neler olduğunu gerçekten anlayan geliştiricilerin en iyisi olduğuna inanıyoruz.

Mutlu inşalarar!