| 18 Jul 2022 |
 K900 | Realistically | 15:57:16 |
 infinisil | Awesome! Some commitment is required, but as long as you're responsive and can keep in touch with the team it should be fine | 16:05:02 |
| infinisil | Feel free to hang around and apply to the team when you feel like it :) | 16:06:16 |
|  ryantm joined the room. | 16:34:14 |
|  Robert Hensing (roberth) joined the room. | 16:41:16 |
| 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 |
