| 19 Sep 2023 |
 @alejandrosame:matrix.org | infinisil: cool, makes sense. I just started using the logic as is (getting rid of the hardcoded lib) because it's really useful to structure also third party repos. I'll keep my example at hand even if I move on from the idea so it serves as a use case demonstration (although I think the overall idea is there to stay in my project). | 14:20:01 |
 infinisil | alejandrosame: Also seeing something similar here https://github.com/ngi-nix/ngipkgs/issues/51 :) | 14:26:49 |
| @alejandrosame:matrix.org | Yeah! I'm also thinking about how to introduce "namespaces". I guess this is really what currently maps to per-framework/language package sets. | 15:07:11 |
| 20 Sep 2023 |
|  nbathum (he or they) changed their display name from nbathum (he or they) to nbathum. | 04:58:35 |
| nbathum (he or they) removed their profile picture. | 04:58:45 |
 Artturin | colemickens: the mechanism of by-name will be useful for us in nixpkgs-wayland | 19:05:57 |
| Artturin | * colemickens: the mechanism of by-name will be useful for us in nixpkgs-wayland ^ | 19:07:45 |
| Artturin | * colemickens: ^ the mechanism of by-name will be useful for us in nixpkgs-wayland | 19:07:52 |
| 21 Sep 2023 |
|  dedmunwalk joined the room. | 23:09:49 |
| 22 Sep 2023 |
|  K900 changed their profile picture. | 09:53:32 |
| infinisil | I want to discuss deviating slightly from the RFC. In particular I think it would make sense to disallow definitions in all-packages.nix like foo = callPackage ../by-name/fo/foo/package.nix { }, but only when the argument is { }. | 19:53:27 |
| infinisil | Currently the RFC specifies that an arbitrary argument is allowed here, but there's no good reason to allow { } arguments. | 19:54:51 |
| infinisil | The main reason I want to change this is because I want to have a check to make sure new packages don't add themselves to all-packages.nix unless necessary (which is when it's not { }). | 19:56:08 |
| infinisil | But it also ensures that for packages that don't need arguments anymore, the definition also gets removed from all-packages.nix | 19:57:48 |
| infinisil | This should be fairly non-controversial, so I'll go ahead with a Nixpkgs PR for this, indicating the slight deviation from the RFC | 19:59:18 |
 @piegames:matrix.org | 👍 | 20:42:44 |
| infinisil | Oof, nixpkgs-check-by-name had a non-reproducible test failure, but here's a PR that fixes it: https://github.com/NixOS/nixpkgs/pull/256774, it's a short one but review/merge appreciated | 22:16:08 |
|  Bryan Honof changed their profile picture. | 22:22:24 |
| 23 Sep 2023 |
| infinisil | I wrote down a strategy for how pkgs/by-name checks could be made more strict over time without randomly breaking stuff: https://github.com/NixOS/nixpkgs/issues/256788 | 00:14:02 |
| infinisil | Well it's generic to any CI check really | 00:14:46 |
| infinisil | In reply to @infinisil:matrix.org
This should be fairly non-controversial, so I'll go ahead with a Nixpkgs PR for this, indicating the slight deviation from the RFC Only a draft for now: https://github.com/NixOS/nixpkgs/pull/256792 | 00:43:49 |
| infinisil | Btw here's the RFC 140 milestone aggregating all of these issues/PRs | 00:52:52 |
| 24 Sep 2023 |
|  mib 🥐 joined the room. | 12:23:48 |
| 27 Sep 2023 |
| mib 🥐 changed their display name from mib to mib 🥐. | 05:53:09 |
|  PowerUser64 joined the room. | 09:30:05 |
| PowerUser64 | After RFC 140 is being used, will packages still have categories of some sort? It seems like it would be a waste to get rid of all the work that has been done to classify 80000+ packages. Personally, I learn about a lot of software just by looking at what other packages are in the categories I use the most. | 09:33:14 |
| @piegames:matrix.org | There's a separate RFC for that | 09:33:55 |
| PowerUser64 | it's also nice when developing a package to be able to see examples of how similar software was packaged right in the same place | 09:34:00 |
| PowerUser64 | Ah good to know | 09:34:08 |
| PowerUser64 | What number is it? | 09:34:19 |
