 | flakelight | 38 Members |
| https://github.com/nix-community/flakelight | 12 Servers |
| flakelight | 38 Members |
| https://github.com/nix-community/flakelight | 12 Servers |
| Sender | Message | Time |
|---|---|---|
| 18 Sep 2025 | ||
 Niclas Overby Ⓝ | * . | 19:22:11 |
| Niclas Overby Ⓝ | With this config: And this layout: Then | 19:26:59 |
| Niclas Overby Ⓝ | When I noticed that nixDirAliases took a list rather than a single string, I actually expected it to behave like this | 19:28:04 |
 accelbread | I see. I'll see if I can make nixDirAliases clearer for the merging directories usecase, I'd recommend having Does that work for your use case? | 19:33:20 |
| accelbread | though making flakelight merge all aliases would also not break things, I think; will need to think over it a bit | 19:35:17 |
| accelbread | it does make sense that having nixosConfigurations/foo.nix and nixos/bar.nix should end up with two systems | 19:37:06 |
| accelbread | though would error on nixosConfigurations/foo.nix and nixos/foo.nix both existing | 19:37:46 |
| accelbread | Yeah, I think it makes sense to have nixDirAliases load all the aliases and merge them | 19:40:35 |
| Niclas Overby Ⓝ | * With this config: And this layout: Then | 19:41:00 |
| 19 Sep 2025 | ||
| Niclas Overby Ⓝ | My motivation for using Flakelight is to reduce boilerplate from flakes and importing Nix files, so in that sense it does not work :) | 08:35:23 |
| Niclas Overby Ⓝ | Another design decision, I'm curious about, is whether all directories should be treated as attribute sets. E.g when creating withOverlays directory, it should actually result in a list rather than an attribute set. | 08:38:37 |
| Niclas Overby Ⓝ |  Download image.png | 08:38:39 |
| Niclas Overby Ⓝ | This layout will of course not work, since with-overlays should result in a list rather than an attribute set. Could it be possible to change Flakelight, so you can decide whether a directory should be treated as a list, rather than an attribute set? | 08:41:03 |
| Niclas Overby Ⓝ | * Another design decision, I'm curious about, is whether all directories should be treated as attribute sets. E.g when creating withOverlays directory, it expects a list rather than an attribute set. | 10:55:55 |
| Niclas Overby Ⓝ | * This layout will not work, since with-overlays should result in a list rather than an attribute set. Could it be possible to change Flakelight, so you can decide whether a directory should be treated as a list, rather than an attribute set? | 10:56:12 |
| accelbread | hmm, i'll have to look into it; not sure if the module system type has enough info | 17:32:31 |
| accelbread | or could be another option like for which should be imported as paths | 17:34:34 |
| accelbread | maybe i can extend the option module with some sort of "import type" | 17:36:27 |
| Niclas Overby Ⓝ | In reply to @accelbread:matrix.orgYeah would be awesome! | 20:16:28 |
| Niclas Overby Ⓝ | * This layout will not work, since with-overlays should result in a list rather than an attribute set. Would it be possible to change Flakelight, so you can decide whether a directory should be treated as a list, rather than an attribute set? | 20:17:30 |
| 20 Sep 2025 | ||
| accelbread | https://github.com/nix-community/flakelight/commit/0326f2bf133b7f83ded8044f11b609ee96e83082 nixDirAliases are now merged when loading | 07:51:50 |
| Niclas Overby Ⓝ | Wow, thank you so much! | 18:31:06 |
| accelbread | https://github.com/nix-community/flakelight/commit/3f5617f2ff25b9349e11312dd84bc9aaaebb7194 List-type options can now be loaded as well | 21:01:51 |
| 21 Sep 2025 | ||
| Niclas Overby Ⓝ | Great! It seems to work wonderfully, when importing overlays that does not need inputs. But how can you handle with overlays like this? | 07:24:54 |
| Niclas Overby Ⓝ |  Download image.png | 07:24:55 |
| Niclas Overby Ⓝ | * Great! It seems to work wonderfully, when importing overlays that does not need inputs. But how can you handle with overlays that require inputs like this? | 13:24:12 |
| accelbread | hmm, at that point its a file expected to be an overlay. I don't know of a way to distinguish I guess it can be deffered to overlay evaluation time like i did in bundlers. I could potentially make that work but even then, the preferred way to write that would be: that should already work. | 17:00:10 |
| accelbread | * hmm, at that point its a file expected to be an overlay. I don't know of a way to distinguish moduleArgs -> overlay from overlay. After one application, both are functions, and after two applications the overlay needs to use the params, so I need the real args. I guess it can be deffered to overlay evaluation time like i did in bundlers. I could potentially make that work but even then, the preferred way to write that would be: final: prev: (import prev.inputs.rust-overlay) final prev that should already work. I'll see if i can make the proposed syntax work though | 17:02:22 |
| accelbread | * hmm, at that point its a file expected to be an overlay. I don't know of a way to distinguish moduleArgs -> overlay from overlay. After one application, both are functions, and after two applications the overlay needs to use the params, so I need the real args. I guess it can be deffered to overlay evaluation time like i did in bundlers. I could potentially make that work but even then, the preferred way to write that would be: ```nix final: prev: (import prev.inputs.rust-overlay) final prev ``` that should already work. I'll see if i can make the proposed syntax work though | 17:02:42 |
| 22 Sep 2025 | ||
| Niclas Overby Ⓝ | Oh great, I didn't know you could do that. :) It would probably still be good to support the proposed syntax, as it is closer to how you usually setup overlays in the main flake.nix | 09:05:04 |