O Mistério por Trás dos Caminhos no Nix Store

Você já reparou naqueles nomes de diretórios assustadores no /nix/store? Parecem que alguém passou o nome de um pacote por um liquidificador criptográfico:

/nix/store/s0psayl7zvkvwdcqc8fy1sbv8rlf1yq8-bash-5.3p9

A parte legível é óbvia — bash-5.3p9 diz exatamente o que tem dentro. Mas e aqueles 32 caracteres antes do hífen? É aí que mora o mistério. E aqui vai a verdade: a maioria das explicações que você vai encontrar por aí está incompleta.

A Explicação Comum (e Errada)

"The hash comes from the inputs" — é isso que a maioria das pessoas vai te dizer. Elas não estão totalmente erradas, mas estão perdendo um detalhe crucial. A pergunta real é: quais inputs exatamente? Estamos falando dos arquivos fonte que você escreveu? Da receita de build que o Nix gera? Dos bytes produzidos pelo build? Das dependências?

A resposta honesta é: depende.

Dois Esquemas de Nomenclatura, Um Único Diretório

O Nix na verdade usa dois mecanismos diferentes para nomear caminhos no store, e ambos convivem pacificamente no /nix/store. É justamente aí que começa a confusão.

Input-Addressed: Nomes Antes do Build

Para a maioria dos builds de pacotes, o Nix funciona como um arquiteto revisando uma planta. Quando você escreve uma expressão .nix, o Nix avalia e transforma isso numa derivation — uma especificação concreta do que construir, incluindo:

• O script de build
• Argumentos de construção
• Variáveis de ambiente
• Outputs declarados
• Dependências

Com essa receita em mãos, o Nix consegue calcular um identificador único antes mesmo de o build rodar. Os binários finais nem existem ainda, mas o Nix já sabe como vai chamá-los.

É por isso que editar uma expressão Nix nem sempre muda o store path. Se suas alterações não afetam a receita de build subjacente, o Nix produz a mesma identidade. Duas expressões diferentes podem avaliar para receitas idênticas, então compartilham o mesmo store path. O Nix nomeia o que vai construir, não a grafia do seu código.

Content-Addressed: Nomes a Partir dos Bytes

O Nix também consegue nomear objetos do store diretamente pelo conteúdo. Quando você roda nix store add, está passando algo que já existe, e ele calcula o hash dos bytes imediatamente. Sem avaliação, sem receita — só conteúdo.

Aqui, o caminho é determinado pelo que realmente está no arquivo. Mude um único byte, e o hash muda.

Por Que Essa Distinção Importa

Entender esses dois esquemas de nomenclatura torna vários comportamentos do Nix subitamente óbvios:

Prevendo mudanças de path. Se você está se perguntando "editar X vai mudar o store path?", pergunte-se: X muda a receita de build ou o conteúdo real? Editar um comentário numa expressão Nix? Provavelmente sem novo path. Mudar versão de uma dependência? Novo path garantido.

Entendendo builds coexistentes. Por que um resultado de build antigo pode ficar ao lado de um novo no store? Porque eles têm identidades diferentes. O Nix não sobrescreve — simplesmente não precisa.

Reuso de cache faz sentido. Um binary cache pode servir tranquilamente um path pré-construído porque o nome identifica unicamente os inputs do build. Mesmo nome significa mesmo conteúdo, garantido.

Mais do Que Apenas um Nome

Um store path nunca está realmente sozinho. Pacotes compilados referenciam outros store paths (libs dinâmicas, interpretadores, assets compartilhados), e o Nix rastreia essas relações como um grafo.

Isso não é só metadado — é um mapa completo de dependências. A partir de qualquer path, você pode traçar sua closure: tudo que precisa viajar junto para funcionar em outra máquina. É assim que o nix-copy-closure funciona, e por que deployments Nix são confiáveis.

O mesmo banco de dados permite ao Nix verificar integridade. Ele consegue checar se os bytes em disco ainda correspondem ao que foi gravado quando o path foi criado. Store paths não são nomes de diretório opacos — são identidades consultáveis com trilha de auditoria completa.

O Recapitulando

Aqueles hashes crípticos não são arbitrários. São o resultado de uma escolha de design deliberada: o Nix nomeia derivações pelos inputs e conteúdos pelos bytes. Essa abordagem dupla é o que torna o Nix reproduzível, verificável e surpreendentemente previsível quando você entende.

Então da próxima vez que vir um store path, não entre em pânico. Leia da direita para a esquerda — essa é a parte legível. O hash à esquerda é só o jeito do Nix de fazer uma promessa: este nome significa este build, e nada mais.

Pronto para mergulhar mais fundo? Seja você deployando containers, gerenciando infraestrutura ou apenas curioso sobre builds reproduzíveis, entender os internos do seu sistema sempre compensa. Na NameOcean, acreditamos que os melhores desenvolvedores são aqueles que entendem o que realmente está acontecendo nos bastidores — não apenas quais comandos rodar.

Boa construção.