| 10 Oct 2025 |
 accelbread | yea, too easy to make self depend on itself if you use its path | 04:09:47 |
| 13 Oct 2025 |
| accelbread | 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 |
| accelbread | I think it'd be confusing to have lib be different values during different parts of evaluation | 03:17:56 |
 Niclas Overby Ⓝ | 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 |
| Niclas Overby Ⓝ | I have noticed that devShells evaluates all nixosConfigurations, if you refer to checks from outputs:
# devShell.nix
pkgs: pkgs.mkShell {
packages = [
outputs.checks.${pkgs.system}.pre-commit-check.enabledPackages
];
}
# checks.nix
{
checks.pre-commit-check = {
inputs,
system,
...
}:
inputs.git-hooks.lib.${system}.run {
src = ./.;
hooks = {
alejandra.enable = true;
statix.enable = true;
ruff-format.enable = true;
};
};
}
| 10:54:30 |
| Niclas Overby Ⓝ | * I have noticed that devShells evaluates all nixosConfigurations, if you refer to checks from outputs:
# devShell.nix
pkgs: pkgs.mkShell {
packages = [
outputs.checks.${pkgs.system}.pre-commit-check.enabledPackages
];
}
# checks.nix
{
checks.pre-commit-check = {
inputs,
system,
...
}:
inputs.git-hooks.lib.${system}.run {
src = ./.;
hooks = {
alejandra.enable = true;
statix.enable = true;
ruff-format.enable = true;
};
};
}
| 10:54:38 |
| Niclas Overby Ⓝ | 
Download flamegraph.svg | 10:55:30 |
| Niclas Overby Ⓝ | I have made a flamegraph to demonstrate it | 10:55:44 |
| Niclas Overby Ⓝ | The offending code is in builtinModules/nixosConfigurations.nix:
checks = foldl recursiveUpdate { } (mapAttrsToList
(n: v: {
# Wrapping the drv is needed as computing its name is expensive
# If not wrapped, it slows down `nix flake show` significantly
${v.config.nixpkgs.system}."nixos-${n}" = v.pkgs.runCommand
"check-nixos-${n}"
{ } "echo ${v.config.system.build.toplevel} > $out";
})
| 11:19:10 |
| Niclas Overby Ⓝ | * The offending code is in builtinModules/nixosConfigurations.nix:
checks = foldl recursiveUpdate { } (mapAttrsToList
(n: v: {
# Wrapping the drv is needed as computing its name is expensive
# If not wrapped, it slows down `nix flake show` significantly
${v.config.nixpkgs.system}."nixos-${n}" = v.pkgs.runCommand
"check-nixos-${n}"
{ } "echo ${v.config.system.build.toplevel} > $out";
})
configs);
| 11:19:36 |
| accelbread | hmm, i'll take a look | 16:13:07 |
| accelbread | might need to use genAttrs | 16:14:12 |
| accelbread | Do you have a flake that reproduces this? | 17:01:39 |
| accelbread | 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 |
| accelbread | v.config.nixpkgs.system should be the only thing needed from each config, and evaluating just that should be fast | 18:14:58 |
| accelbread | * <nixos value>.config.nixpkgs.system should be the only thing needed from each config, and evaluating just that should be fast | 18:16:20 |
| accelbread | * <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 |
| accelbread | 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 |
| accelbread | would make it more reusable and encapsulated | 18:28:05 |
| accelbread | upstream repo has flake-parts module; maybe they'd accept a flakelight module | 18:31:42 |
| 23 Oct 2025 |
| Niclas Overby Ⓝ | 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 |
| Niclas Overby Ⓝ | Redacted or Malformed Event | 09:34:48 |
| Niclas Overby Ⓝ | 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 |
| Niclas Overby Ⓝ | 
Download flamegraph.svg | 09:37:48 |
| 25 Oct 2025 |
| Niclas Overby Ⓝ | Would you still like this? | 13:54:52 |
| accelbread | that would help yes | 16:46:19 |
| accelbread | In reply to @niclas:overby.me
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. if 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 |
| accelbread | i could add a config to not do that but trying to figure if i can make the calculation cheaper | 16:50:50 |
| accelbread | how are you generating the graphs btw? | 17:40:16 |
| accelbread | seems passing system to nixosSystem is deprecated, so pushed some updates to use the buildSystem/targetSystem replacements instead | 19:31:57 |
