| 18 Sep 2025 |
 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 |
| accelbread | so withOverlays = overlay is automatically converted to withOverlays = [ overlay ] by the module system | 15:21:18 |
| accelbread | ah that explains it | 15:24:36 |
| accelbread | you can usually do { inputs, ...}: ... in a file because those options support being set to a function that takes module args | 15:25:52 |
| accelbread | this should be distinguishable though | 15:26:53 |
| accelbread | testing a change that enables taking args when loading withOverlays | 16:36:34 |
| accelbread | given that withOverlays = overlay is confusing with module args (i.e. cant do { inputs, ... }: final: prev: { ... }, must do {inputs, ... }: [( final: prev: { ... })]), and that I dont see others' repos on Github using that form, I'll deprecate the withOverlays = overlay syntax in favor of explicitly writing withOverlays = [ overlay ] | 16:41:41 |
| accelbread | Actually, don't need to deprecate that | 16:48:11 |
| accelbread | https://github.com/nix-community/flakelight/commit/464ab0a32efcc4310eef119cfc6c470e267cd42a | 16:59:47 |
| accelbread | this should work now with the new commit | 17:01:15 |
| accelbread | will need {inputs, ...}: instead of just {inputs}: | 17:03:34 |
| accelbread | Is there an issue with importing lib from nix/lib/default.nix? It already can take module args | 17:11:26 |
| Niclas Overby Ⓝ | No I just assumed it didn't work either. | 19:06:40 |
| Niclas Overby Ⓝ | Nice thanks! :) | 19:07:19 |
| Niclas Overby Ⓝ | How is nixDirAliases suppose to work?
Is it really allowed to have multiple aliases, so you can e.g. have multiple folders with packages definitions like:
nixDirAliases = {
packages = ["dir1" "dir2"];
};
| 19:09:49 |
| Niclas Overby Ⓝ | * How is nixDirAliases suppose to work?
Is it really allowed to have multiple aliases, so you can e.g. have multiple folders with packages definitions like:
nixDirAliases = {
packages = ["dir1" "dir2"];
};
| 19:10:05 |
| accelbread | Its intended to allow using "nixos" instead of "nixosConfigurations" and so on | 19:11:55 |
| accelbread | so you can give alternative names for dirs for that attribute | 19:12:24 |
| accelbread | first one will be used | 19:12:28 |
| accelbread | so with nixDirAliases.foo = [ "bar" ] if theres no nix/foo.nix or nix/foo/ then nix/bar.nix and nix/bar/ will be checked and used equivalently | 19:13:55 |
| Niclas Overby Ⓝ | But why is it a list then? | 19:14:27 |
| accelbread | multiple aliases can exist, like if you wanted nixosConf to also work | 19:15:06 |
| accelbread | nixDirAliases.foo = [ "bar" "baz" ] checks all of the foo, bar, and baz paths in order and uses the first one to set foo | 19:16:05 |
| Niclas Overby Ⓝ | Oh makes sense, but it could also be useful, if you could have multiple aliases that merges together :) | 19:18:02 |
| accelbread | hmm, yeah that could be possible | 19:19:13 |
| accelbread | Do you have an example of how you'd use it? Like for multiple dirs of packages? | 19:20:24 |
| Niclas Overby Ⓝ | Redacted or Malformed Event | 19:22:02 |
