| 27 Nov 2024 |
|  Birhaman changed their profile picture. | 19:29:02 |
| Birhaman removed their profile picture. | 19:29:25 |
| Birhaman set a profile picture. | 19:31:40 |
|  enderbsd joined the room. | 20:14:35 |
 magic_rb | It also builds iirc | 22:51:04 |
|  TheDragon left the room. | 23:33:46 |
| 28 Nov 2024 |
|  loaonline joined the room. | 02:21:37 |
|  sheeeng joined the room. | 07:45:34 |
 Leonardo Santiago |
wondering how many nixpkgs you are instantiating 🤔
should be just one, they're all using the same one.
| 13:21:34 |
| Leonardo Santiago | *
wondering how many nixpkgs you are instantiating 🤔
should be just one, they're all using the same one.
| 13:21:44 |
| Leonardo Santiago |
It also builds iirc
yes, but even with --no-build it's still painfully slow. it's the same default check, and most of the structure should be shared for all of them, it seems to me that nix must be re-evaluating a ton for it to take that much time
| 13:22:48 |
 ElvishJerricco | In reply to @o-santi:matrix.org
wondering how many nixpkgs you are instantiating 🤔
should be just one, they're all using the same one.
Just because they're using the same nixpkgs flake input doesn't mean they're using the same nixpkgs instance. Each nixos config by default re-imports nixpkgs (re-evaluates it) so that it can apply its custom nixpkgs.* nixos options to the import | 13:36:58 |
| Leonardo Santiago | hmm, but they should all be using the exact same nixpkgs.lib.nixosSystem call. is there any way to avoid re-evaluating nixpkgs? | 13:37:49 |
| ElvishJerricco | right but each of those calls does (effectively) import ./. { /* ... */ } in the nixpkgs flake | 13:38:34 |
| ElvishJerricco | You can avoid re-evaluating by setting pkgs in the nixosSystem call, I believe. Or by setting the nixpkgs.pkgs nixos option. Either of this will break anything in the nixpkgs.* nixos options (though I think that module yells at you about that now so it'll be obvious) | 13:39:59 |
| ElvishJerricco | * You can avoid re-evaluating by setting pkgs in the nixosSystem call, I believe. Or by setting the nixpkgs.pkgs nixos option. Either of these will break anything in the nixpkgs.* nixos options (though I think that module yells at you about that now so it'll be obvious) | 13:40:16 |
| ElvishJerricco | that said, I'm not even sure nixpkgs eval is the slowest part tbh. NixOS module evaluation might be worse, and you're not going to get that to be shared | 13:41:15 |
| Leonardo Santiago | In reply to @elvishjerricco:matrix.org
that said, I'm not even sure nixpkgs eval is the slowest part tbh. NixOS module evaluation might be worse, and you're not going to get that to be shared I imagined it, which is sad. the design is pretty modular, as in, it should be able to evaluate the modules separately and then just re-use them for all configs. I was wondering if there was a way to restructure my code to do it like that. | 13:53:08 |
| ElvishJerricco | I mean that's not really possible | 13:53:36 |
| Leonardo Santiago | but I don't know enough about the internals of nix flake check for that | 13:53:37 |
| ElvishJerricco | any module can affect any other module arbitrarily | 13:53:43 |
| ElvishJerricco | so if two configs aren't literally exactly identical (I mean exactly) then there's basically zero potential for sharing | 13:54:20 |
| Leonardo Santiago | that is fair, I didn't think about that | 13:54:23 |
| ElvishJerricco | Leonardo Santiago: I'd give it a try to reduce the nixpkgs instantiations by setting them all to the same pkgs and see how much that helps | 13:55:21 |
| Leonardo Santiago | I'll try doing that | 13:56:24 |
| Leonardo Santiago | I'm also experimenting with nix-eval-jobs --flake .#nixosConfigurations but it doesn't seem to do what I want? it either returns instantaneously with no output or enters an infinite loop with --force-recurse | 13:57:23 |
| Leonardo Santiago | not sure I'm using it correctly | 13:57:30 |
| ElvishJerricco | Leonardo Santiago: You probably need to specify the exact toplevel attributes, not just nixosConfigurations | 15:05:26 |
| ElvishJerricco | i.e. I'd create an output attribute like toplevels = mapAttrs (_: cfg: cfg.system.build.toplevel) self.nixosConfigurations; and eval that | 15:06:34 |
| Leonardo Santiago | what does that mean? I'd like for it to evaluate each nixosConfiguration under that in it's own thread. how would I do it? spell out each attr I'd like it to eval in there? | 15:06:35 |
