Nix Hackers | 911 Members | |
| For people hacking on the Nix package manager itself | 190 Servers |
| Sender | Message | Time |
|---|---|---|
| 8 Mar 2025 | ||
| a lot of things that user posts are wrong. you do have to copy your sources with pure eval though, which sort of reduces to being flakes in many ways people care about | 17:57:56 | |
In reply to @emilazy:matrix.org Needing to copy sources is unfortunate, sure, but seeing as flakes also do that anyways, shouldn't matter much And this approach doesn't require any changes to be done to the cppnix source code | 18:00:43 | |
| "needing to copy sources" is not an absolute need, I think, no? | 18:01:30 | |
| lazy trees is exactly about removing that requirement | 18:01:35 | |
| more generally, the problem of purity in presence of sources is the one of installing a virtual filesystem layer | 18:01:55 | |
| I think "you have to write your own deployment thing and it has to have the main thing people hate about the flakes UX" is not insignificant | 18:02:43 | |
| i'm gonna steal this, thank you | 18:02:47 | |
In reply to @raitobezarius:matrix.orgAbsolutely, but again, that's kinda detached from the flakes as builtins.path can also absolutely be made lazy | 18:02:51 | |
In reply to @weethet:catgirl.cloudthis I meant ^ | 18:02:55 | |
| 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 | 18:03:00 | |
In reply to @emilazy:matrix.orgIt's me saying that and I observed that directly | 18:03:31 | |
WeetHet: btw, I suggest you use darwin-rebuild activate from the built system | 18:03:34 | |
| (and raitobezarius too if copying it) | 18:03:39 | |
| it will reduce churn down the line | 18:03:54 | |
In reply to @emilazy:matrix.orgI think there's one place where it's actually true | 18:03:57 | |
In reply to @emilazy:matrix.orgI'm using flakes rn due to the above said performance issues | 18:04:06 | |
| Flakes are not configurable (except with that new configurable flakes features) | 18:04:06 | |
Non-Flakes are by nature already configurable via --argstr | 18:04:13 | |
| sorry then :D | 18:04:13 | |
In reply to @emilazy:matrix.org* | 18:04:18 | |
| Non-Flakes pure evaluation cannot avoid dealing with "how do you cache in presence of configuration" | 18:04:26 | |
| Flakes pure eval does not need to deal with this | 18:04:32 | |
| 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 | |
| (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 | |
| Yeah my system evaluation with flakes vs without has a sizable (a second or so) difference in evaluation times | 18:05:32 | |
| * | 18:05:47 | |
| are we just talking about installable eval caching? | 18:05:48 | |
the thing where foo#bar gets an evaluation result cachd? | 18:05:56 | |
| yeah, I'm mostly talking about this | 18:05:57 | |
* the thing where foo#bar gets an evaluation result cached? | 18:05:58 | |