| 8 Jun 2026 |
inomena | Redacted or Malformed Event | 17:28:48 |
inomena | * like this snippet from a module I have for disko:
{ lib, config, inputs, ... }:
let
cfg = config.flake.disks;
in {
options.flake.disks = {
device = lib.mkOption {
type = lib.types.str;
default = "";
};
};
config = lib.mkIf cfg.device != "" {
imports = [
inputs.disko.nixosModules.disko
];
disko.devices.disk.root = {
device = cfg.device;
type = "disk";
content = {
| 17:28:59 |
inomena | oh neat, matrix code blocks support ligatures | 17:29:27 |
accelbread | yeah i meant flakelightModules in same flake. for exporting extensions to flakelight | 17:29:59 |
| 13 Jun 2026 |
inomena | one problem I found with this is that it's not recursive, i.e. only top-level modules are imported | 15:43:06 |
accelbread | what do you mean by that? like modules stored in subdirs? | 19:00:32 |
inomena | yeah exactly, I've got a pattern where I group/nest modules based on their context, i.e. I have a desktop module, within that module I have a gnome module, etc | 20:39:57 |
inomena | to be explicit; nix/nixosModules/desktop/default.nix, nix/nixosModules/desktop/gnome/default.nix, etc | 20:41:16 |
| 14 Jun 2026 |
accelbread | Ah yeah, since the schema of nixosModules is an attrset, the loading logic is to load nix/nixosModules as attrs; it'll load desktop/default.nix as "desktop" | 21:12:00 |
accelbread | flakelight expects the filesystem layout to match the flake attr layout | 21:12:31 |
accelbread | if you want those to be part of your desktop module, your desktop module can import them by path | 21:13:33 |
accelbread | if you want them to be exported from the flake separately from the desktop module, you'd have to put it at top-level | 21:14:09 |
inomena | yeah I figured | 23:33:56 |
inomena | maybe using import-tree or something would solve my case, need to try that out | 23:34:21 |
accelbread | yeah, long-term I plan to clean the autoloading code up in order to make it more extensible, so people can write a module that customizes autoloading to however they want it | 23:52:00 |
| 4 Jul 2026 |
| Niclas Overby Ⓝ changed their profile picture. | 23:24:42 |
| 8 Aug 2025 |
| 0x4A6F joined the room. | 07:02:20 |
| 14 Sep 2025 |
| Emma [it/its] joined the room. | 08:39:50 |
| 15 Sep 2025 |
| @bestlem:matrix.org left the room. | 10:22:07 |
| 18 Sep 2025 |
Niclas Overby Ⓝ |  Download image.png | 10:21:01 |
Niclas Overby Ⓝ | Hi accelbread ! Have you considered supporting something like this in Flakelight, so that input overlays can be moved to the withOverlays folder? | 10:22:56 |
Niclas Overby Ⓝ | And actually the same for lib, so you can use pkgs in lib | 10:25:48 |
Niclas Overby Ⓝ | * And actually the same for lib, so you can use pkgs in the lib folder | 10:27:02 |
accelbread | that should already work, right? | 14:36:21 |
Niclas Overby Ⓝ | It seems to cause an infinite recursion | 14:39:24 |
Niclas Overby Ⓝ |  Download image.png | 14:39:26 |
accelbread | Ah, I see. I'll take a look | 14:41:40 |
accelbread | interestingly, something like the following in nix/withOverlays/default.nix works:
final: prev: (prev.lib.composeManyExtensions [
prev.inputs.nixgl.overlays.default
prev.inputs.emacs-overlay.overlays.package
prev.inputs.self.overlays.overrides
prev.inputs.self.overlays.lix
]) final prev
So computing the module arguments is triggering evaluation of withOverlays... hmm
| 15:10:09 |
Niclas Overby Ⓝ | Does it make sense that this is supported?: (How does Flakelight know whether it is an overlay or a function to setup multiple overlays, like in my example ?)
withOverlays = overlay;
Shouldn't it only support?:
withOverlays = [overlay, ...];
| 15:18:28 |
accelbread | ah it's type is defined as optListOf overlay; if what its set to is a list, its used as is, if its not a list its put in one | 15:20:29 |