| 20 Jul 2022 |
 infinisil | We shouldn't block ourselves on Nix though | 17:32:54 |
 Gytis Ivaskevicius | In reply to @k900:0upti.me
Yo how did we go from "let's move some files around" to "let's build a new bootstrap" John Ericson: is a very charming man, please let him continue charming us with low level nix legacy <3 | 17:33:09 |
 John Ericson | https://github.com/NixOS/hydra/pull/1180 | 17:33:30 |
| John Ericson | this should happen | 17:33:38 |
| John Ericson | "small functions are confusing" is not good | 17:33:52 |
| Room Avatar Renderer. | 18:35:46 |
| infinisil | Logo from Gytis Ivaskevicius's collection here! https://github.com/gytis-ivaskevicius/high-quality-nix-content/blob/master/emoji/nix-shooting.png | 18:36:13 |
| 21 Jul 2022 |
| Room Avatar Renderer. | 08:12:42 |
| infinisil | Another Logo from Gytis Ivaskevicius :D | 08:13:22 |
 Rick (Mindavi) | In reply to @Ericson2314:matrix.org
this should happen ca-derivations in hydra in general would be great and I think a good base for some improvements, it's not super clear to me why it's all so stuck | 08:20:50 |
 Théophane | In reply to @rick:matrix.ciphernetics.nl
ca-derivations in hydra in general would be great and I think a good base for some improvements, it's not super clear to me why it's all so stuck It's mostly stuck bc of Hydra. Making hydra support it cleanly is a lot of painful work | 09:08:01 |
| Rick (Mindavi) | And the current efforts are not clean enough then? | 09:43:40 |
| Théophane | They are as good as can reasonably bee, but hydra re-implements in its own way half of the Nix build loop, and any real “clean” solution would probably need to first get rid of that duplication, which would be more work than what anyone has available for Hydra right now | 09:52:21 |
| Rick (Mindavi) | Ah okay, so hydra should start using the build loop from nix itself at some point to really have a clean integration? | 09:54:26 |
| Théophane | I think so, yes | 09:56:35 |
 yorik.sar | I would be awesome to have all Hydra eval and build features in Nix itself. | 09:56:23 |
 Alyssa Ross | 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. | 10:10:53 |
| 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 |
