| 21 Jul 2022 |
 Alyssa Ross | hmm, did that message come through as a reply? it was supposed to | 10:11:10 |
 yorik.sar | Yes, it did | 10:21:22 |
| Alyssa Ross | cool, thanks | 10:24:16 |
 Sandro | the logo reminds me of https://en.wikipedia.org/wiki/FC_Bayern_Munich | 11:39:56 |
 hexa | same | 12:01:14 |
 j-k | 
Download nix_architecture.png | 12:24:56 |
| j-k | my candidate | 12:25:00 |
| j-k | helmet from FontAwesome's free tier which I imagine we can use
https://fontawesome.com/icons/helmet-safety?s=solid
can swap it for a better one if necessary | 12:26:03 |
| 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 |
