| 18 Jul 2022 |
 Robert Hensing (roberth) |
Hi, I'd like to be a Nixpkgs Architecture Team member.
My motivation for joining: I want Nix to succeed, and Nix can only succeed with a healthy Nixpkgs. I've been monitoring the PR queue for architecturally relevant or otherwise interesting changes, but that only goes so far. With this team, we can facilitate larger, more impactful changes.
I'd also like to join the GitHub team (as @roberth)
My time will be sponsored by Hercules CI.
The current meeting time slot works for me.
Thank you @infinisil for pointing me here. | 17:01:06 |
 infinisil | Awesome! I have a lot of trust in you Robert Hensing (roberth), I've really enjoyed working with you on various issues regarding the NixOS module system :D | 17:03:56 |
| infinisil | I'd like to accept your application, but I need to check with the only other current team member. tomberek do you also agree with Robert Hensing (roberth) joining the team? | 17:04:34 |
 tomberek | In reply to @infinisil:matrix.org
I'd like to accept your application, but I need to check with the only other current team member. tomberek do you also agree with Robert Hensing (roberth) joining the team? Absolutely agree. | 17:51:43 |
| infinisil | Awesome, welcome to the team then Robert Hensing (roberth)! I added an entry for you in the team log and the team list, you were also invited into the github organization :) | 18:03:50 |
| infinisil | Robert Hensing (roberth): Do you want an invite to the meetings? That way you automatically get email updates when it changes and can RSVP. I'd need an email for that (can PM me) | 18:04:49 |
| infinisil | Also open to non-members by the way, let me know if anybody wants an email invite to the weekly meetings | 18:06:21 |
| infinisil | I created a project board to track issues this team might work on: https://github.com/orgs/nixpkgs-architecture/projects/2/views/2 | 21:12:51 |
| infinisil | I added some items myself, and I'll probably add more soon, but anybody is free to open new issues here that they'd like the nixpkgs architecture team to address: https://github.com/nixpkgs-architecture/issues/issues | 21:14:10 |
| 19 Jul 2022 |
|  Taeer Bar-Yam joined the room. | 13:57:40 |
| 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 |
