| 21 Jul 2022 |
 Sandro 🐧 | In reply to @j-k:matrix.org
sent an image. kinda looks like prometheus upside down without the flame 🤔 | 12:59:03 |
 Robert Hensing (roberth) | In reply to @qyliss:fairydust.space
strongly disagree with having higher-level builder hooks, for exactly this reason. As it stands, setup hooks compose much better than high-level Nix derivation wrapper functions. setup hooks don't have a per derivation eval overhead, whereas you pay an eval price for every feature that's in a mkDerivation wrapper | 13:01:08 |
 Alyssa Ross | also a good point | 13:01:36 |
| Robert Hensing (roberth) | In reply to @qyliss:fairydust.space
strongly disagree with having higher-level builder hooks, for exactly this reason. As it stands, setup hooks compose much better than high-level Nix derivation wrapper functions. * also, setup hooks don't have a per derivation eval overhead, whereas you pay an eval price for every feature that's in a mkDerivation wrapper | 13:01:38 |
 yorik.sar | I think we should optimise the evaluation process, not try to avoid it... | 13:35:59 |
 John Ericson | yeah setup hooks cannot be the solution | 14:10:32 |
| John Ericson | agree today's builder functions are no ogod | 14:10:41 |
| John Ericson | * agree today's builder functions are no good | 14:10:44 |
| Alyssa Ross | why can't the be the solution? | 14:11:16 |
| John Ericson | they are just too jank for for me, and when you do need eval time info they are no good | 14:11:42 |
| Alyssa Ross | I think setup hooks are great, as they allow package authors to simply declare the dependencies, and most of the time the right thing will happen. If it doesn't, it's easy to disable the problematic setup hooks and do things manually. | 14:12:32 |
| John Ericson | e.g. if we wanted to do build-cc cc target-ccrather thanmachine-cc` in wrapper would be nice to have some sort of eval level setup hook to build the wrapper with different prefix depending on how it is used | 14:12:45 |
| John Ericson | Well, what I really believe is Nix needs more layering so we can get a better diversity of approaches | 14:13:30 |
| John Ericson | it's very hard to steer nixpkgs at all right now | 14:13:48 |
| Alyssa Ross | wdym by layering? | 14:13:59 |
| John Ericson | I want to be able to build store layer without eval or falkes | 14:14:14 |
| John Ericson | * I want to be able to build store layer without eval or flakes | 14:14:17 |
| John Ericson | and have a binary for it | 14:14:24 |
| John Ericson | and try to standardize that between guix and us | 14:14:36 |
 infinisil | Not sure if I get the main problem here. Is it something like eval time vs build time computation? | 14:14:36 |
| Alyssa Ross | Noble cause, but is it relevant to stdenv? | 14:14:43 |
| Alyssa Ross | or setup hooks vs builders? | 14:15:10 |
| John Ericson | if we have more experimentaiton but interopt at the higher level, we can have "farm teams" trying out ideas and Nixpkgs can pick the best ones | 14:15:17 |
| infinisil | And setup hooks are currently build time, but because of that it doesn't allow eval time inspection? And how does that relate to wrapping? Can't there be eval or build time wrapping? | 14:15:31 |
| John Ericson | * if we have more experimentaiton but interopt at the higher level, we can have "farm teams" trying out ideas and Nixpkgs can pick the best ones. That's how they connect. | 14:16:15 |
 j-k | In reply to @Ericson2314:matrix.org
and try to standardize that between guix and us makes me think of the modularity discussed in tvix but IDK if there has been much progress there
https://tvl.fyi/blog/rewriting-nix
| 14:17:07 |
| John Ericson | they are still doing things I understand, but yes this should be driven by the foundation | 14:18:46 |
| John Ericson | it is some technological work but also more importantly believing that multiple approaches is good, vs everyone must use exprs or flakes or whatever | 14:19:21 |
| John Ericson | I do think nickle or hnix or something will give us types | 14:20:02 |
| John Ericson | not C++ nix | 14:20:09 |
