| 8 Mar 2025 |
 emily | WeetHet: btw, I suggest you use darwin-rebuild activate from the built system | 18:03:34 |
| emily | (and raitobezarius too if copying it) | 18:03:39 |
| emily | it will reduce churn down the line | 18:03:54 |
 raitobezarius | In reply to @emilazy:matrix.org
there's also some talk that maybe some eval perf improvements only apply to flakes but not non-flakes pure eval, though I find that claim dubious without substantiation I think there's one place where it's actually true | 18:03:57 |
 WeetHet | In reply to @emilazy:matrix.org
WeetHet: btw, I suggest you use darwin-rebuild activate from the built system I'm using flakes rn due to the above said performance issues | 18:04:06 |
| raitobezarius | Flakes are not configurable (except with that new configurable flakes features) | 18:04:06 |
| raitobezarius | Non-Flakes are by nature already configurable via --argstr | 18:04:13 |
| emily | sorry then :D | 18:04:13 |
| WeetHet | In reply to @emilazy:matrix.org
WeetHet: btw, I suggest you use darwin-rebuild activate from the built system * | 18:04:18 |
| raitobezarius | Non-Flakes pure evaluation cannot avoid dealing with "how do you cache in presence of configuration" | 18:04:26 |
| raitobezarius | Flakes pure eval does not need to deal with this | 18:04:32 |
| raitobezarius | Thus, there's scenarios with Flakes pure eval can always beat non-Flakes pure eval by the virtue of just not having one feature (configuration) that requires more work to make cacheable | 18:04:52 |
| raitobezarius | (I mean, saying this out loud makes me realize that well, making it cacheable trivial and hash consing all the exact same set of inputs used is a way to do it) | 18:05:21 |
| WeetHet | Yeah my system evaluation with flakes vs without has a sizable (a second or so) difference in evaluation times | 18:05:32 |
| WeetHet | * | 18:05:47 |
| emily | are we just talking about installable eval caching? | 18:05:48 |
| emily | the thing where foo#bar gets an evaluation result cachd? | 18:05:56 |
| raitobezarius | yeah, I'm mostly talking about this | 18:05:57 |
| emily | * the thing where foo#bar gets an evaluation result cached? | 18:05:58 |
| emily | because if so, WeetHet, I'm not sure you're measuring something that worthwhile for system configs | 18:06:13 |
| emily | a single byte change in the flake will throw away the entire eval cache | 18:06:22 |
| raitobezarius | I agree this is a cheat but this is user visible | 18:06:23 |
| emily | right. well it matters for nixpkgs# for sure | 18:06:30 |
| emily | for system configs … meh | 18:06:37 |
| WeetHet | I don't know why this happened, really. It's not even evaluation catching probably since --impure evaluation is still faster | 18:07:20 |
| WeetHet | * | 18:07:30 |
| WeetHet | * | 18:08:03 |
| WeetHet | There's also an issue of me having nixpkgs being pinned to a github rev in the flake registry which works fine with flakes but causes a noticeable delay with a message "fetching github<...>" when using nix-shell even if it's already fetched | 18:12:41 |
| WeetHet | It doesn't actually fetch it, but for some reason takes an unreasonable time checking for it ig | 18:13:09 |
| WeetHet | Overall, all this just makes non-flake UX just miserable enough for me to use flakes even though I really don't want to | 18:14:13 |
