| 30 Aug 2023 |
 infinisil | No problem ;) | 10:47:02 |
| infinisil | Nice, the pkgs/by-name CI check runs in about 30 seconds! https://github.com/NixOS/nixpkgs/actions/runs/6026577029/job/16349848006?pr=237439 | 15:00:39 |
| 31 Aug 2023 |
| infinisil | 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. | 18:28:28 |
| infinisil | Now there's two options, either: | 18:29:05 |
| infinisil |
- Keep the category hierarchy alive only for new packages of that kind
| 18:29:39 |
| infinisil |
- Deprecate the category hierarchy and introduce something like
pkgs/alt-callPackage, where you can put all packages of that kind
| 18:30:39 |
 K900 | We can absolutely get rid of libsForQt5.callPackage and qt6Packages.callPackage | 18:31:04 |
| infinisil | Both kind of suck but also aren't very significant, but I think in order to keep the number of changes to a minimum I'll go with the first one | 18:31:07 |
| K900 | At least | 18:31:08 |
| K900 | But we can do that in a follow-up | 18:31:17 |
| infinisil | It's a bit tricky because there seems to be some cross compilation shenanigans sometimes | 18:31:46 |
| K900 | In fact I'd really like to get rid of those and maybe get smaller better scoped package sets for KF6/Plasma6/KDE Gear stuff | 18:31:50 |
| K900 | qt6Packages isn't even spliced | 18:32:02 |
| K900 | And qt5 cross was broken until like two days ago | 18:32:20 |
| infinisil | See also my little rant from yesterday: https://matrix.to/#/!kjdutkOsheZdjqYmqp:nixos.org/$U5DUxbsottP-50Q5d0PQYHnX0xZdNpJDJ4hXiNkBdfs?via=nixos.org&via=matrix.org&via=nixos.dev | 18:32:24 |
| infinisil | But yeah, all of those callPackages could be gotten rid of, but that also does affect the derivation interface, and it makes the definitions a bit more complicated, so I don't want to touch that in that PR | 18:33:17 |
 Alyssa Ross | whoa can we cross compile QT 5 now? | 18:33:17 |
| 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 |
