| 28 Oct 2025 |
 emily | has anyone ever looked at if evaluating all the NixOS tests has some specific hot spot? | 17:04:03 |
| emily | is it instantiating a billion Nixpkgs? just the module system being slow? | 17:04:13 |
 K900 | It is both | 17:04:18 |
| K900 | I tried https://github.com/K900/nixpkgs/tree/less-nixpkgses and somehow in our testing on forkos hydra it made things worse | 17:04:38 |
 Vladimír Čunát | Wolfgang Walther is also looking at it, apparently. | 17:04:39 |
| Vladimír Čunát | Let's see who's faster 😅 | 17:04:52 |
| K900 | Which makes no fucking sense | 17:04:57 |
| emily | Hydra eval is parallelized with nix-eval-jobs, right? | 17:05:51 |
| emily | is anything shared between the evaluations of multiple NixOS tests? | 17:05:58 |
| Vladimír Čunát | I'm more worried about the expenses to run all the tests. | 17:06:29 |
| Vladimír Čunát | Because I can see the huge difference between e.g. trunk and trunk-combined. | 17:06:42 |
| Vladimír Čunát | We're spending a surprising amount of Hydra's "real time" on the added tests. | 17:07:04 |
| Vladimír Čunát | Hydra's eval itself tends not to be a real bottleneck. (though in CI it would be bad) | 17:08:03 |
| Vladimír Čunát | * Hydra's eval itself tends not to be a real bottleneck. (though in CI it would be very bad) | 17:08:14 |
 dish [Fox/It/She] | is there no way to parallelize the transaction by splitting it? | 17:35:27 |
| Vladimír Čunát | It would certainly help with the deadlocks and blocking other updates to the DB. | 17:36:33 |
| Vladimír Čunát | It often happens that Hydra stalls for several minutes because of such huge write transaction just happening. | 17:37:14 |
| K900 | There definitely is | 17:39:53 |
| K900 | Hydra is just an ancient Perl monstrosity | 17:40:00 |
 hexa | lol, I remember getting yelled at for nuking old aliases a while ago | 17:40:36 |
| hexa | the tl;dr is … just do it quietly? | 17:40:56 |
| hexa | or wait until we have a nixpkgs core team that can make that call? | 17:41:25 |
| Vladimír Čunát | runCommandNoCC will surely have some usage outside nixpkgs, too. | 17:41:50 |
| hexa | it was about e.g. pkgconfig = pkg-config back then | 17:42:07 |
| emily | it wasn't very quiet IMO… it's only ones that were already in 25.05 | 17:45:19 |
| emily | there was discussion about whether to go through a warning cycle for the ones without them or throw immediately | 17:45:41 |
| emily | we could still backtrack and attach warnings to those ones | 17:45:56 |
 Wolfgang Walther | Yeah, I'd say we could do that on a case-by-case basis, if there is reason for a specific case. | 17:46:27 |
| Wolfgang Walther | Was the argument that this should actually persist forever? If so, we'll just need to mark the alias as such instead. | 17:46:53 |
| emily | in practice unstable changes in ways that produce throws all the time I think, in this case it's at least a way that you can handle downstream without breaking compat with any supported release | 17:46:55 |
