| 31 Aug 2023 |
 infinisil | * But yeah, all of those callPackages could be gotten rid of, but that also does affect the override interface, and it makes the definitions a bit more complicated, so I don't want to touch that in that PR | 18:33:28 |
 K900 | Yes, and all it took was like five screens of drama | 18:34:40 |
 raitobezarius | Well, amjoseph is probably the one behind it I guess | 18:35:11 |
| infinisil | In reply to @infinisil:matrix.org
Question for https://github.com/NixOS/nixpkgs/pull/237439:
We can almost declare all top-level packages in pkgs/by-name, except ones that should be declared using e.g. python3Packages.callPackage, libsForQt5.callPackage, etc. So then, regarding this, I think it should be fine to say that new top-level packages should always be added to pkgs/by-name | 18:40:59 |
| infinisil | Because there shouldn't be a need to use e.g. python3Packages.callPackage for new packages | 18:41:14 |
| infinisil | Although.. that does change conventions | 18:41:23 |
| infinisil | Nah let's not do that, I'll just mention that you still have to use the category hierarchy and all-packages.nix for those cases. | 18:41:51 |
| infinisil | It's likely that conventions automatically change to not use alternate callPackage's anymore from that | 18:42:14 |
| K900 | For python3Packages maybe we'd want a secondary hierarchy | 18:42:09 |
| K900 | Like pkgs/python/by-name/* | 18:42:15 |
| K900 | Just because there's a lot of them | 18:42:23 |
| infinisil | Non-top-level packages are another store | 18:42:43 |
| infinisil | * Non-top-level packages are another story | 18:42:44 |
| infinisil | RFC 140 and pkgs/by-name is indeed only concerned with top-level packages | 18:42:55 |
| infinisil | @room As with last week, I have now cleaned up https://github.com/NixOS/nixpkgs/pull/237439, part 1b of RFC 140. Please review this until Tuesday, where we have a meeting scheduled to do a final review and merge (if everything looks good)! The meeting is on 2023-09-05 15:30 CEST in https://meet.jit.si/nixpkgs-architecture and anybody is invited, but the most members of the Nixpkgs Architecture Team are expected to be there. | 21:12:33 |
