flakelight | 38 Members | |
| https://github.com/nix-community/flakelight | 12 Servers |
| Sender | Message | Time |
|---|---|---|
| 9 Oct 2025 | ||
| Yeah, it only seems to work with
| 11:36:07 | |
| * Yeah, it only seems to work with
| 12:21:26 | |
| 10 Oct 2025 | ||
| yea, too easy to make self depend on itself if you use its path | 04:09:47 | |
| 13 Oct 2025 | ||
| yeah I don't think applying modifications to lib makes sense. If enabled, then the value of lib would be different when resolving imports vs config | 03:17:22 | |
| I think it'd be confusing to have lib be different values during different parts of evaluation | 03:17:56 | |
| Fair, but it would be nice if Flakelight has a opinionated way to add helper functions, that will be made available everywhere like with packages. It does not have to be by modifying lib, but I'm not sure what the alternative could be. | 09:25:49 | |
| 22 Oct 2025 | ||
| I have noticed that devShells evaluates all nixosConfigurations, if you refer to checks from outputs:
| 10:54:30 | |
| * I have noticed that devShells evaluates all nixosConfigurations, if you refer to checks from outputs:
| 10:54:38 | |
Download flamegraph.svg | 10:55:30 | |
| I have made a flamegraph to demonstrate it | 10:55:44 | |
| The offending code is in
| 11:19:10 | |
| * The offending code is in
| 11:19:36 | |
| hmm, i'll take a look | 16:13:07 | |
| might need to use genAttrs | 16:14:12 | |
| Do you have a flake that reproduces this? | 17:01:39 | |
| I couldn't reproduce the issue with my nixos config at the moment. I pushed 5afd705 which cleans up the logic and slightly reduces the use of the nixos config in evaluating attrs; that may help, but unsure | 18:13:46 | |
| v.config.nixpkgs.system should be the only thing needed from each config, and evaluating just that should be fast | 18:14:58 | |
* <nixos value>.config.nixpkgs.system should be the only thing needed from each config, and evaluating just that should be fast | 18:16:20 | |
* <nixos value>.config.nixpkgs.system should be the only thing needed from each config, and evaluating just that should be fast; rest should be lazy under evaluating the runCommand script | 18:17:02 | |
| though overall, for something like pre-commit, would be better to write a flakelightModule that adds options for the precommit config, generates the preconfig packages, and sets the devShell/checks using those | 18:27:25 | |
| would make it more reusable and encapsulated | 18:28:05 | |
| upstream repo has flake-parts module; maybe they'd accept a flakelight module | 18:31:42 | |
| 23 Oct 2025 | ||
| The graph looks different, but it still takes substantial longer time to init the devshell, because it loads all the nixosConfigurations. There are quite a lot of nixosConfigrations in the project, which might contribute to why it is slow in my project compared to yours. | 09:34:44 | |
| Redacted or Malformed Event | 09:34:48 | |
| I'm still not sure why the check is needed in the first place? It seems to be a performance footgun with projects with many nixosConfigurations. | 09:36:36 | |
Download flamegraph.svg | 09:37:48 | |
| 25 Oct 2025 | ||
| Would you still like this? | 13:54:52 | |
| that would help yes | 16:46:19 | |
In reply to @niclas:overby.meif you have a nixos configuration, you wouldn't want nix flake check to pass if it didn't build right? same as why other packages are added to checks. though to evaluate what checks are available under checks.${systems} it needs to know the systems of the nixosConfigurations | 16:49:47 | |
| i could add a config to not do that but trying to figure if i can make the calculation cheaper | 16:50:50 | |