| 20 Jul 2022 |
|  wiredhikari joined the room. | 06:58:29 |
 infinisil | Just discussed with Robert Hensing (roberth) in #dev:nixos.org some things relating to .overrideAttrs | 08:37:21 |
 Robert Hensing (roberth) | In reply to @infinisil:matrix.org
Just discussed with Robert Hensing (roberth) in #dev:nixos.org some things relating to .overrideAttrs Discussion started at https://matrix.to/#/!kjdutkOsheZdjqYmqp:nixos.org/$c_CLLdpbxqzeOS3o1CM4uPc029OBnK2hXrKnp-oQVGM?via=nixos.org&via=matrix.org&via=nixos.dev | 08:37:38 |
| infinisil | For one, something like https://github.com/NixOS/nix/pull/4154 (changed to something like builtins.lazyAttrUpdate) could allow all these .overrideAttrs, .extend, .overrideScope, etc. to not require evaluating the old value at all | 08:38:17 |
| infinisil | But also with a different standard builder, .overrideAttrs at least wouldn't be a problem anymore. Robert Hensing (roberth) showed how that could look like here: https://github.com/NixOS/rfcs/pull/92#discussion_r671741003 | 08:39:18 |
| infinisil | (the problem mainly being that .overrideAttrs has some performance overhead because of how all the attributes of the derivation need to be known beforehand) | 08:40:26 |
| infinisil | If derivations don't contain all their arguments as output attributes anymore, we could have a static set of output attributes, which then means less evaluation needed to get to .overrideAttrs | 08:42:12 |
| infinisil | I hope I summarized this well | 08:42:17 |
| Robert Hensing (roberth) | My concern with lazy attribute names is that its performance benefit may be insignificant after implementing such a change in Nixpkgs, while incurring the cost of complicating the Nix evaluator forever | 08:45:08 |
|  FRidh joined the room. | 08:45:59 |
|  teto joined the room. | 08:46:35 |
| 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 |
