Tajemnicze nazwy w Nix Store – wyjaśniamy raz a porządnie

Widziałeś je na pewno. Te przerażające nazwy katalogów w /nix/store, które wyglądają jakby ktoś podał nazwę pakietu przez maszynkę do szyfrowania:

/nix/store/s0psayl7zvkvwdcqc8fy1sbv8rlf1yq8-bash-5.3p9

Czytelna część nie stanowi problemu – bash-5.3p9 mówi dokładnie, co siedzi w środku. Ale te 32 znaki przed myślnikiem? Tu zaczyna się zagadka. I oto coś istotnego: większość wyjaśnień, które znajdziesz, jest niepełna.

Popularne (i błędne) wyjaśnienie

„Hash pochodzi od danych wejściowych" – tak większość ludzi tłumaczy. Nie są do końca w błędzie, ale brakuje im kluczowych niuansów. Prawdziwe pytanie brzmi: jakich danych wejściowych? Czy hashujemy pliki źródłowe, które napisałeś? Przepis budowania generowany przez Nix? Bajty powstałe w wyniku kompilacji? Zależności?

Szczerze? To zależy.

Dwa schematy nazewnictwa, jeden katalog

Nix w praktyce stosuje dwa różne mechanizmy nazewnictwa dla ścieżek w sklepie i oba spokojnie współistnieją w /nix/store. Pomieszanie ich to początek całego zamieszania.

Podejście oparte na danych wejściowych (input-addressed)

Przy większości kompilacji pakietów Nix działa jak architekt przeglądający projekty. Kiedy piszesz wyrażenie .nix, Nix ewaluuje je do derivacji – konkretnej specyfikacji tego, co trzeba zbudować, zawierającej:

• Skrypt budujący
• Argumenty kompilacji
• Zmienne środowiskowe
• Deklarowane wyniki
• Zależności

Mając ten przepis, Nix jest w stanie wyliczyć unikalny identyfikator zanim kompilacja w ogóle się rozpocznie. Gotowe pliki binarne jeszcze nie istnieją, ale Nix już wie, jak je nazwać.

Dlatego edycja wyrażenia Nix nie zawsze zmienia ścieżkę w sklepie. Jeśli twoje zmiany nie wpływają na sam przepis budowania, Nix generuje tę samą tożsamość. Dwa różne wyrażenia mogą ewaluować do identycznych przepisów, więc dzielą tę samą ścieżkę. Nix nazywa to, co zbuduje – nie samą pisownię twojego kodu.

Podejście oparte na zawartości (content-addressed)

Nix potrafi też nazywać obiekty w sklepie bezpośrednio na podstawie ich zawartości. Kiedy wpisujesz nix store add, wręczasz Nixowi coś, co już istnieje, a on natychmiast hashuje bajty. Zero ewaluacji, zero przepisów – tylko zawartość.

Tu ścieżka zależy od tego, co faktycznie znajduje się w pliku. Zmień jeden bajt – hash się zmienia.

Dlaczego ta różnica ma znaczenie

Zrozumienie tych dwóch schematów nazewnictwa sprawia, że wiele zachowań Nix staje się nagle oczywistych:

Przewidywanie zmian ścieżek. zastanawiasz się „czy edycja X zmieni ścieżkę w sklepie?" Zapytaj siebie: czy X zmienia przepis budowania czy faktyczną zawartość? Edytujesz komentarz w wyrażeniu Nix? Prawdopodobnie bez zmiany ścieżki. Zmieniasz wersję zależności? Nowa ścieżka gwarantowana.

Zrozumienie współistniejących kompilacji. Dlaczego stary wynik kompilacji może leżeć obok nowego w sklepie? Bo mają różne tożsamości. Nix nie nadpisuje – po prostu nie musi.

Ponowne użycie cache ma sens. Binary cache może pewnie serwować prekompilowaną ścieżkę, bo nazwa jednoznacznie identyfikuje dane wejściowe kompilacji. Ta sama nazwa oznacza tę samą zawartość, punkt.

Więcej niż tylko nazwa

Ścieżka w sklepie nigdy nie jest naprawdę samotna. Skompilowane pakiety odwołują się do innych ścieżek w sklepie (dynamiczne biblioteki, interpretery, współdzielone zasoby), a Nix śledzi te relacje jako graf.

To nie jest tylko metadane – to kompletna mapa zależności. Z dowolnej ścieżki możesz prześledzić jej closure: wszystko, co musi z nią podróżować, żeby działała na innej maszynie. Tak działa nix-copy-closure i dlatego deploymenty w Nix są niezawodne.

Ta sama baza danych pozwala Nix weryfikować integralność. Może sprawdzić, czy bajty na dysku wciąż odpowiadają temu, co zarejestrował przy tworzeniu ścieżki. Ścieżki w sklepie to nie tajemnicze nazwy katalogów – to sprawdzalne tożsamości z pełnym logiem audytu.

Podsumowanie

Te tajemnicze hashe nie są przypadkowe. To efekt świadomej decyzji projektowej: Nix nazywa derivacje ich danymi wejściowymi, a zawartość jej bajtami. To dualne podejście sprawia, że Nix jest reprodukowalny, weryfikowalny i – gdy raz to zrozumiesz – zaskakująco przewidywalny.

Więc następnym razem, gdy zobaczysz ścieżkę w sklepie, nie panikuj. Czytaj od prawej do lewej – tam jest część dla ludzi. Hash po lewej to sposób Nix na złożenie obietnicy: ta nazwa oznacza tę kompilację i nic innego.

Chcesz zgłębić temat? Niezależnie od tego, czy wdrażasz kontenery, zarządzasz infrastrukturą, czy po prostu ciekawią cię reprodukowalne kompilacje, zrozumienie wewnętrznych mechanizmów systemu zawsze się opłaca. W NameOcean wierzymy, że najlepsi developerzy to ci, którzy rozumieją, co naprawdę dzieje się pod maską – a nie tylko które komendy wpisać.

Miłego budowania.