| 26 Jul 2025 |
 emily | there is pkgs.extend, but generally overlays in Nixpkgs are only used for stdenv bootstrap. my understanding was that the point of lixPackageSets was to have the overrides that you can overlay directly, but I'm not 100% sure | 16:39:16 |
| emily | (so you can also pkgs.extend pkgs.lixPackageSets.<version>, in non-NixOS) | 16:39:39 |
| emily | (er, type error) | 16:39:53 |
 @aloisw:julia0815.de | In reply to @piegames:flausch.social
e.g. pkgs.lixOverlay, which takes a Lix derivation and produces an overlay which overrides all packages that depend on Nix to use that derivation Do you want to use this in a particular place? Or just expose it to users? | 16:40:11 |
| @aloisw:julia0815.de | In reply to @emilazy:matrix.org
I thought the idea was to do something like nixpkgs.overlays = [ (final: prev: prev.lixPackageSets.<version>) ]; or something? That probably does not really work, given that lixPackageSets has some non-Lix packages in it, and the Nix implementation is called lix there and not nix. | 16:41:08 |
| emily | fair enough. I thought that was the general idea, but I can believe the implementation is not there yet :) | 16:41:35 |
| emily | nix = lix; seems like an easy enough fix, though | 16:41:43 |
| emily | having non-Lix packages in it is the point, right? to overlay stuff that depends on Nix | 16:41:52 |
| @aloisw:julia0815.de | I mean that's basically what the nixos-module does right? | 16:42:02 |
| emily | e.g. it has nixpkgs-review and so on | 16:42:17 |
 Qyriad | Technically it's what the overlay that the nixos-module adds does | 16:42:30 |
| emily | the module does the opposite | 16:42:48 |
| @aloisw:julia0815.de | 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:julia0815.de | 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:julia0815.de | 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:julia0815.de | 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 |
