| 26 Jul 2025 |
 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 |
| emily | it doesn't take parameters | 16:58:50 |
| piegames | * which is basically like that one except the overlay gets access to its inputs, in a way (not sure if that even adds anything useful in the first place though) | 16:58:52 |
| emily | overlays = [ pkgs. can never work | 16:58:59 |
| emily | overlays = [ (final: prev: prev.dummyOverlay) ]; should | 16:59:06 |
| emily | I don't think you need the arguments in lixPackageSets | 16:59:39 |
| emily | its "prev" is essentially the wider package set it's instantiated in | 17:00:04 |
| aloisw | In reply to @emilazy:matrix.org
"prefetch-yarn-deps" # force these onto upstream so we are not regularly rebuilding electron
has some clue
Am I looking at the correct thing here https://github.com/NixOS/nixpkgs/blob/7379d27cddb838c205119f9eede242810cd299a7/pkgs/development/tools/electron/common.nix#L53-L56 ? That's a FOD. | 17:00:16 |
