| 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 |
| PowerUser64 | * After RFC 140 is in full effect, 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:35:51 |
| @piegames:matrix.org | 156 I think? | 09:36:31 |
| PowerUser64 | hmm that one is "No Direct Nixpkgs Pushes" | 09:37:42 |
