| 19 Oct 2025 |
 raboof | nix-store -q --graphml (of nix-store -q --tree) on a derivation shows what derivations it depends on, but not which specific outputs. That seems fairly easy to add (famous last words), should I? Or is there a better way to get this information anyway? | 13:10:27 |
| raboof | * nix-store -q --graphml (or nix-store -q --tree) on a derivation shows what derivations it depends on, but not which specific outputs. That seems fairly easy to add (famous last words), should I? Or is there a better way to get this information anyway? | 13:10:46 |
|  azahi left the room. | 15:46:49 |
| 20 Oct 2025 |
 fzakaria | is that --outputs or something | 03:03:28 |
| fzakaria | i can never remember all the query flags | 03:03:33 |
|  flacks changed their profile picture. | 04:36:54 |
 Martin Schwaighofer | In reply to @jfly:matrix.org
My question is stronger than "can we?". I'm saying "mustn't we?" I think if you're not looking at the paths or derivations the semantics of that would be the same.
Maybe it would be a conceptual simplification. | 17:26:05 |
| Martin Schwaighofer | I really like the idea of having a more explicit resolution step, that all derivations go through, which could model this and the distinction between content- and input-addressed derivations.
To me, this is is the way to make this stuff easier to understand in Nix.
We would teach users about two dependency trees, an unresolved one, and a resolved one, and the resolution step to get from one to the other. The unresolved one is based on recursive hashes of inputs, like input-addressed paths, the resolved one is based on content hashes of inputs, like content-addressed paths.
You can model both input-addressed derivations and content-addressed derivations uniformly this way, it's just that how you address things on disk is different, and which versions of the derivations have more abstract or explicit placeholders for which data.
The unresolved tree would contain the unresolved input hash of the FOD, the resolved tree would contain the hard-coded content hash.
Expanding on that view, and in practice, you would have to do resolution in two steps. First resolve all of the FODs to their hard-coded content hashes and base IA paths on that (equivalent to the hash-modulo thing), and then interactively resolve and build all of other derivations between the closest satisfied FODs and the build target.
You could do
```
nix derivation show --{unresolved,fod-resolved,resolved} nixpkgs#hello
```
to understand and teach this.
CA derivations have resolved versions already, but it's not surfaced that nicely to users yet. You can also drop input-addressing, or not change it, but still expose and teach it that way. | 17:28:10 |
| Martin Schwaighofer | I think the hash modulo thing is meant to prevent the path of C changing as well. | 17:36:46 |
| Martin Schwaighofer | * I really like the idea of having a more explicit resolution step, that all derivations go through, which could model this and the distinction between content- and input-addressed derivations.
To me, this is is the way to make this stuff easier to understand in Nix.
We would teach users about two dependency trees, an unresolved one, and a resolved one, and the resolution step to get from one to the other. The unresolved one is based on recursive hashes of inputs, like input-addressed paths, the resolved one is based on content hashes of inputs, like content-addressed paths.
You can model both input-addressed derivations and content-addressed derivations uniformly this way, it's just that how you address things on disk is different, which versions of the derivations have more abstract or explicit placeholders for which data, and how strict they are with resolution.
The unresolved tree would contain the unresolved input hash of the FOD, the resolved tree would contain the hard-coded content hash.
Expanding on that view, and in practice, you would have to do resolution in two steps. First resolve all of the FODs to their hard-coded content hashes and base IA paths on that (equivalent to the hash-modulo thing), and then interactively resolve and build all of other derivations between the closest satisfied FODs and the build target.
You could do
```
nix derivation show --{unresolved,fod-resolved,resolved} nixpkgs#hello
```
to understand and teach this.
CA derivations have resolved versions already, but it's not surfaced that nicely to users yet. You can also drop input-addressing, or not change it, but still expose and teach it that way. | 17:40:30 |
 lovesegfault | Alright, there's a lot of room for bike shedding, but the RequiredSignatures in nix-cache-info idea is up: https://github.com/NixOS/nix/pull/14313 | 22:32:52 |
