The biggest problem of all is that derivers are not unique! A separate "build trace" map will solve this.

Presumably this would support a big improvement to both SBOM generation as well as various UX features and workflow improvements.

is that the 'build-trace' feature I saw John write about ? (I want to explore that more)

The core store layer is quite small, and I am trying to thoroughly document it, with all 3 of:

- a more "academic" spec of what it does

- nuts-and-bolts JSON schema for many data types

- JSON golden tests instead of C++ literals in the unit tests as often as possible.

I hope this will make additional store layer easy to churn out.

(The "hash derivation modulo" that is so fiddly described in this blog post can be dropped in a world where we no longer have input addressing, and just have content-addressing. Or, in a world where we have a new, simpler type of input-addressing instead.)

Well, there's Guix as an alternative if you want a similar concept but different implementation philosophy. For me the major disadvantage of Guix is lack of package availability compared to Nix.

I feel the same about HCL in Terraform. The tool is perfect, the language is bollocks.

Eh. This can be applied to so many technologies that run the world..

It has been rewritten a few times already. The "fixed output hash" is a dirty optimisation hack borne out of real-world needs and not a research idea.

Yes, a hope of mine is that we can stop using "hash derivation modulo" entirely.

I've recently started some fancy formal spec-level documentation here https://github.com/NixOS/nix/pull/14408 The "resolution" equivalence class is both simpler and better than the "hash derivation modulo ..." one.

(The fact that it is a mouthful to say what the derivations are modulo kinda gives the game away! I put "hash quotient derivation" in the docs to side-step the issue.)

To be clear, there is no bug here: derivers are simply not uniquely determined in the presence of fixed-output derivations, which is by design. That's even more true with CA derivations.

CA derivations also introduce the opposite situation, namely that the same derivation can produce different output paths for different users (if the build is not bitwise reproducible).

ca-derivations from what i understand, fixed-output derivations but more general.

The point of the article to me (author) was that i found it odd that Nix replaces the derivations when calculating the output path but not the derivation path. (talking about "paths" in Nix is so hard!)

The package name is "secondary" information in this context. The hash is the primary one because it's stable unless the input changes.

The semantic is "what did this configuration generate", not "what's this package's version".

In nix packages (derivations) are so lightweight that your store has tens of thousands of them, many with the same name, or with no meaningful name at all. On the rare occasions that you need to look in the store for a package you’re much more likely to be looking for a particular hash than a particular name. That, and having the hash as a prefix looks nicer in tabular output.

It really doesn't matter. As a normal user, you don't use `drv` files directly, and everything you configure yourself will use attribute paths in nixpkgs. E.g. `pkgs.ruby` or `pkgs.ruby_3_3`.

It's done that way on purpose. Precisely so you don't try to use the paths semantically. The names literally mean nothing in this context.

The reason it's like this is because the only way to reliably grab it is to cut the string at the first hyphen - then the rest can be almost free text.

It you do it the other way it's harder. You can try this with nix commands /nix/store/<hash>-x is a valid way to refer to something in the store most of the time.