 | Nix Hackers | 884 Members |
| For people hacking on the Nix package manager itself | 192 Servers |
| Nix Hackers | 884 Members |
| For people hacking on the Nix package manager itself | 192 Servers |
| Sender | Message | Time |
|---|---|---|
| 18 Oct 2025 | ||
 dramforever | you don't have to eval to download stuff from cache.nixos.org, there's nix copy | 15:27:54 |
| dramforever | uh, with --substitute-on-destination | 15:28:16 |
| dramforever | or you can nix copy --from https://cache.nixos.org a path | 15:28:31 |
| dramforever | but the point is no, it won't always be present locally | 15:28:55 |
 raboof | right, you can, but I wondered if/when that happens in practice | 15:30:58 |
| dramforever | --substitute-on-destination definitely happens in practice | 15:32:11 |
 fzakaria | anyone want to pair/hack tonight? | 20:11:25 |
| fzakaria | Question I was confused by Jeremy Fleischman (jfly) : When calculating store-paths, Nix does "Hashing modulo fixed-output derivations" -- this makes sense since you want the store-path to be stable for multiple drvs for the FOD. His question: | 20:54:21 |
| fzakaria |  Download image.png | 21:04:07 |
| fzakaria | The part we are confused about: B.drv may have many different A.drv ; That's OK because eventually A.drv is replaced with A.outPath... BUT C depends on B.drv ... wouldn't that path have changed since the contents of the drv can have N A.drv paths | 21:04:58 |
 Jeremy Fleischman (jfly) | My question is stronger than "can we?". I'm saying "mustn't we?" | 21:42:26 |
| 19 Oct 2025 | ||
 lovesegfault | I'd appreciate some feedback on https://github.com/NixOS/nix/pull/14298, in particular regarding this:
| 01:59:05 |
 cedricgc joined the room. | 03:38:04 | |
| 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 |
 Jean changed their profile picture. | 04:36:54 | |
 Martin Schwaighofer | In reply to @jfly:matrix.org 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 |
| 21 Oct 2025 | ||
| fzakaria | Sergei Zimmerman (xokdvium): that makes sense The confusing part is that the inputDrvs for non-FODs are not replaced with their output path but FODs are when caculating the out paths. The drv's path though is just the hash of the ATerm ?This has the side-effect of causing brand new drvs for the whole system tree since drvs are just the hash of their ATerm without substitution? | 00:02:43 |
| fzakaria | I was going to explore the Katai struct. Is nars.sh and nar-access.sh the only NAR tests? | 00:04:46 |
 Sergei Zimmerman (xokdvium) | In reply to @fzakaria:one.ems.hostSome invalid cases in libutil-tests/archive.cc also | 00:05:36 |
| fzakaria | should nix nar ls work on NAR that only have a single file ? | 04:28:31 |
| fzakaria | I started the kaitai spec here: https://github.com/fzakaria/nix-nar-kaitai-spec/tree/main tested directories and regular files so far. There is a test program that is mostly AI generated i need to fix | 05:08:27 |
| fzakaria | https://github.com/fzakaria/nix-nar-kaitai-spec/blob/main/NAR.ksy | 05:08:55 |