| 26 Jul 2025 |
 aloisw | Wait it does things other than adding an overlay? | 16:42:57 |
 emily | mostly enumerating exceptions to a general overlay | 16:42:57 |
 Qyriad | So most of the logic is in the overlay | 16:43:11 |
| emily | as opposed to explicitly having nix-direnv, nix-eval-jobs, etc. like lixPackageSets does (which is more upstreamable) | 16:43:17 |
| Qyriad | It also adds two configuration options for optionally disabling Lix | 16:43:27 |
| emily | OTOH, boehmgc, editline, etc. would certainly have to go | 16:43:33 |
| aloisw | In reply to @emilazy:matrix.org
as opposed to explicitly having nix-direnv, nix-eval-jobs, etc. like lixPackageSets does (which is more upstreamable) Ah, I see what you want to do. Your suggestion might actually be enough for that. | 16:44:13 |
| Qyriad | I stand corrected: just one https://git.lix.systems/lix-project/nixos-module/src/commit/4d4c2b8f0a801c91ce5b717c77fe3a17efa1402f/module.nix#L7-L13 | 16:44:16 |
| emily | "I" here is just "my understanding of the plan to upstream the module as seen in https://wiki.lix.systems/books/lix-contributors/page/2025-06-26-lix-nixos-module" | 16:44:44 |
| emily | admittedly, if nix = lix; was added, you'd start needing all the exceptions again | 16:44:54 |
| emily | anyway I guess you'd either need to move the internal deps like editline into another scope, or you'd need to move the "stuff overridden to use Lix" into a sub-scope that can be used as an overlay. | 16:45:55 |
| emily | and then you have the question of whether to nix = lix; (I think nixForLinking was meant to make this possible without needing exception hacks) or just enumerate stuff to override | 16:46:21 |
| aloisw | Lol nixForLinking was made to not be overridden by Lix? | 16:47:32 |
| emily | that's my understanding | 16:47:56 |
| emily | (I think it was originally cppnix? with predictable results.) | 16:48:18 |
| emily | blanket overriding stuff that links against the API doesn't make sense since there's no promise of compatibility there, I think. though in some cases I imagine the issue is just the number of rebuilds | 16:48:58 |
| aloisw | I must have been lucky then my configuration did not break given its overlay has:
nix = stableLix;
nixForLinking = stableLix;
nixVersions = builtins.throw "nixVersions is disabled";
| 16:49:03 |
| emily | I guess now that nix-prefetch-git doesn't pull Nix into a billion closures it's probably not that many rebuilds | 16:49:33 |
| aloisw | How many packages depend on nix-prefetch-git outside of fixed-output derivations?! | 16:50:37 |
| aloisw | I do remember a couple of infinite recursions involving that, but I think it did not even use nixForLinking? | 16:51:06 |
 piegames | npins etc. | 16:52:46 |
| emily | I remember it was a lot but I don't remember why. | 16:53:24 |
| emily | well, it doesn't link. it shells out. but it no longer pulls in Nix by default I think | 16:53:42 |
| aloisw | Anyway regarding exposing the overlay from nixpkgs, it seems that trying to add the overlay to the same pkgs instance used to get it will cause infinite recursion. | 16:54:24 |
| emily | "prefetch-yarn-deps" # force these onto upstream so we are not regularly rebuilding electron
has some clue
| 16:54:25 |
| emily | with prev, not final? | 16:54:44 |
| aloisw | I have tested something like let pkgs = import ./. { overlays = [ pkgs.dummyOverlay ]; }; in pkgs. | 16:55:19 |
| piegames | nixpkgs = import <nixpkgs> { overlays = [ (self: super: { myOverlay = self: super: {}; }) (self: super: super.myOverlay self super) ]; } works though | 16:56:50 |
| piegames | So import <nixpkgs> { overlays = [ (self: super: super.ourLixOverlay self super) ]; } should work | 16:57:50 |
| piegames | which is basically like that one except the overlay gets access to its inputs, in a way | 16:58:29 |
