| 11 Mar 2024 |
 @jonringer:matrix.org | Transparency is always appreciated. Thank you. | 16:18:53 |
| @jonringer:matrix.org | I understand that doing candidate selection can be sensitive. I would be fine with some discretion. I think I was more advocating for a statement like,
The Nixpkgs Architecture team met, and unanimously decides to move foward with both candidates. We are happy to welcome <personA> and <personB> to our team.
If someone was passed over, just a civil statement as to why I think would suffice.
Sorry if my paranoia in some opaque community interactions spilled over into other teams.
| 16:31:11 |
 infinisil | Yeah, I was only able to disclose it in full this time because nothing personal was being discussed, definitely shouldn't become standard | 16:38:39 |
 nbp | I second the feeling. Thanks for doing this extra effort and keeping the other channel on track. | 17:01:14 |
| nbp | * I second the feeling. Thanks for doing this extra effort and keeping the other channel on topic. | 17:01:19 |
| infinisil changed the room topic to "Discussions about Nixpkgs' architecture - https://github.com/NixOS/nixpkgs/labels/architecture" from "https://nixos.org/community/teams/nixpkgs-architecture.html -https://www.youtube.com/@nixpkgs-architecture". | 17:06:51 |
| 12 Mar 2024 |
|  @benjaminedwardwebb:envs.net joined the room. | 02:38:19 |
| 13 Mar 2024 |
|  @ktemkin:katesiria.org changed their display name from Kate Temkin to [K]ate Temkin. | 02:56:13 |
| 14 Mar 2024 |
|  @federicodschonborn:matrix.org left the room. | 02:04:38 |
|  NixOS Moderation Botchanged room power levels. | 18:44:58 |
| infinisil | Philip Taron (UTC-8): Just a minor comment: https://github.com/NixOS/nixpkgs/pull/293901#discussion_r1525395621 | 19:34:13 |
 Philip Taron (UTC-8) | Thanks! 👀 | 19:34:45 |
| Philip Taron (UTC-8) |
What's the reason behind using lib only for some fields but lib.<sublib> for others? E.g. attrNames comes from lib, but isDerivation comes from lib.attrsets, even though they're available in both.
Dang, I still struggle with this in lib. If there is a rhyme or reason for having some names be re-exported from lib vs. some names being only available in lib.sublib, I can't find it.
| 19:36:19 |
| infinisil | There totally isn't 😅 | 19:37:17 |
| infinisil | There's a problem with re-exporting everything, because of conflicts, but I agree this should be improved somehow 🤔 | 19:38:07 |
| infinisil | relevant comment and reply: https://github.com/NixOS/nixpkgs/pull/293835#pullrequestreview-1929937012 | 19:38:37 |
| Philip Taron (UTC-8) | This was the first PR I made against lib, so the historical reason is that I was trying to do the work by hand and I didn't have the script I later wrote to gather and use the names automatically. | 19:39:05 |
| infinisil | Haha I see | 19:39:35 |
| Philip Taron (UTC-8) | I've formed a small bias towards the shortest path. So if a name is re-exported from lib, I'll use that. | 19:39:58 |
| Philip Taron (UTC-8) | * Since I opened the PR, I've formed a small bias towards the shortest path. So if a name is re-exported from lib, I'll use that. | 19:40:11 |
| infinisil | Philip Taron (UTC-8): Sounds good to me | 19:42:32 |
| Philip Taron (UTC-8) | I still have Robert's feedback (and now yours) to go and digest in the lib/trivial.nix PR. | 19:42:47 |
| Philip Taron (UTC-8) | Note that that PR, unlike the rest, isn't about with removal -- it was mostly formed because of my trying to make sense of how lib is structured, so getting on the same page with you and robert about it is key for my future contributions in the area. | 19:43:50 |
| Philip Taron (UTC-8) | But I can keep gathering that knowledge about it on a low simmer instead of a strong boil; digesting approaches takes time. | 19:45:20 |
| infinisil | Haha great way to word it | 19:46:35 |
| Philip Taron (UTC-8) | I do have a couple of conclusions after reading through most of lib/:
lib.or was mostly a mistake. Having a token that's part of the Nix grammar also be an identifier is really ambiguous. lib.and has the same problem.- Having an explicit list of symbols to export definitely reduces the chance of exporting a helper function that isn't used outside of
lib. For instance, lib.systems.parse exports gnuNetBSDDefaultExecFormat, and I bet it didn't mean to.
let ... in blocks are great.- Whether to use
lib or builtins is made substantially harder by lib not being a drop-in for builtins.
| 19:54:22 |
| infinisil | Philip Taron (UTC-8):
- Oh damn didn't realise that, though I never used
or nor do I see a good use case for it. I think lib.and should be fine, since there's no and keyword
- +1
- +1
- Yeah.. I think this should be fixed, though I guess some builtins might not make sense in
lib, like builtins.import or builtins.fetchGit (or does it?)
| 19:58:30 |
| Philip Taron (UTC-8) | There's no and keyword? There's an and token and a production that uses it... | 19:59:57 |
| infinisil | Philip Taron (UTC-8): That's && :P | 20:00:28 |
| Philip Taron (UTC-8) | In reply to @infinisil:matrix.org
Philip Taron (UTC-8): That's && :P 🤦 | 20:00:48 |
