| 20 Jul 2022 |
 infinisil | I have seen a lot of motivations for lazy attribute names by now. There's many use cases with a dynamic set of attributes that's expensive to evaluate, but where you have some function that can make changes to that set exposed conveniently with a .<something> | 08:46:49 |
 Robert Hensing (roberth) | mkDerivation spilling the derivation guts out is a problem that we should solve regardless, and whether that's through a mkDerivation-like function or mkPackage, we'll evaluate derivation attribute names more quickly | 08:46:57 |
| infinisil | I only see two solutions right now: Making the attributes static, or to use something like lazy attribute names. The former does come with a convenience disadvantage, the latter with complicating the Nix implementation (though I don't think it will be considerable) | 08:48:22 |
| Robert Hensing (roberth) | I'm not against it. Just saying that we should be really careful, as its costs are hard to assess, and its benefit might not be as big in the future | 08:48:33 |
| Robert Hensing (roberth) | I don't think there's a convenience disadvantage when we improve mkDerivation. mkPackage is currently overkill, as we don't have RFC 92 yet (derivations producing derivations), and mkPackage is a little inconvenient compared to mkDerivation | 08:50:24 |
| Robert Hensing (roberth) | Though it would be interesting to "rebase" a mkDerivation replacement on mkPackage instead of custom fixpoint stuff | 08:51:21 |
| infinisil | Short summary of how lazy attribute names should be implemented in Nix:
- Create an attribute set abstraction, so that there can be multiple "backends" of values providing attributes. This will be some tree-wide changes, but there's also other Nix ideas that could use this abstraction (functions as attribute sets is the one I know of)
- Add a new value type, a lazy attribute update, consisting of two values (left and right)
- Add a
builtins.lazyAttrsUpdate builtin that creates such a value
| 08:53:26 |
| infinisil | The first point is the most time-consuming one, but I know how to go about it. After that it's smooth sailing | 08:54:12 |
| infinisil | Whether this is in scope for this team, I'm not sure, but I see a lot of value we could get from this for nixpkgs :) | 08:55:33 |
 j-k | as discussed in the meeting, if this was discourse this would be quite a bit easier to follow
cc: infinisil | 08:58:36 |
| infinisil | j-k: Not disagreeing, but I think Matrix has a place for quick discussions | 09:02:02 |
| infinisil | Though it's hard to know when to use Matrix vs Discourse. Should discussions from Matrix be summarized in Discourse like a meeting log? Might make sense if we consider Matrix as just textual meetings | 09:04:54 |
| infinisil | Is it okay to reach out to somebody in Matrix when you want to quickly chat about a Discourse post? I'd think so, but then it's easy to not follow up on Discourse | 09:05:36 |
 Alyssa Ross | can't you link to relevant Matrix logs on Discourse? | 09:06:38 |
| infinisil | Going from audio/video meetings, over Matrix to Discourse, you lose efficiency, but you gain persistence 🤔 | 09:06:46 |
| infinisil | Alyssa Ross: Oh that sounds pretty good | 09:07:07 |
| infinisil | Would be cool if there was a Matrix GitHub integration, where GitHub could show a Matrix conversation inline | 09:07:59 |
| infinisil | Or s/GitHub/Discourse | 09:09:46 |
|  adisbladis joined the room. | 09:27:51 |
| infinisil | Regarding GitHub vs Discourse, I think both have their place: GitHub for task tracking and persistent development discussions, while Discourse is better when we need feedback from the wider community and end-users | 09:41:34 |
|  tim joined the room. | 09:54:38 |
| infinisil | Made some proposed adjustments to the main team document, feel free to take a look: https://github.com/nixpkgs-architecture/.github/pull/2 | 10:00:27 |
|  lvkm joined the room. | 10:56:55 |
|  squalus joined the room. | 13:00:09 |
| infinisil | We'll have the second meeting shortly! | 14:53:14 |
|  mkaito joined the room. | 14:58:25 |
| infinisil | @room Next meeting is now in https://meet.jit.si/nixpkgs-architecture if you want to join :) | 15:01:21 |
 Taeer Bar-Yam | Alas, I can't make it today. Next time! | 15:01:57 |
| j-k | same. have a work demo to deliver | 15:02:36 |
| infinisil | Thanks for joining again everybody! Feel free to fix up https://pad.lassul.us/uIi7xeSJTW6LJUEHulZgVQ a bit, I'll only put it into the meetings repository later | 16:05:39 |
