| 26 Jul 2025 |
 piegames | Finally made meeting notes for this, CC K900 raitobezarius Please double-check the conclusion section if you can
https://wiki.lix.systems/books/lix-contributors/page/2025-06-26-lix-nixos-module | 16:29:31 |
| piegames | Quick side question: can we define overlays within Nixpkgs and directly use them, or does this result in infinite recursion because non-lazy attrs and thus require a double-import of Nixpkgs? | 16:33:49 |
| piegames | nvm we of course can't I'm dumb | 16:34:22 |
| piegames | so this begs the question, pkgs.lixPackageSet is overlay-shaped but how to apply it (in a non-NixOS setting especially) | 16:34:50 |
 aloisw | Depends on what you mean by "within nixpkgs" I guess? | 16:34:54 |
| piegames | (side question, how does this even work with NixOS with config.nixpkgs.overlays, how does it bootstrap itself there) | 16:35:21 |
 Qyriad | pkgs.config doesn't contain overlays | 16:36:33 |
| Qyriad | I think like, pkgs' = import <nixpkgs> { overlays = [ pkgs.lixOverlay ]; }? | 16:37:01 |
| piegames | 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 | 16:37:16 |
 emily | I thought the idea was to do something like nixpkgs.overlays = [ (final: prev: prev.lixPackageSets.<version>) ]; or something? | 16:38:33 |
| piegames | I'll take that if it works | 16:39:04 |
| 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 | 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 | 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 | 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 | 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 |
