| 11 Mar 2024 |
 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 |
