| 12 Sep 2023 |
 Alyssa Ross | that's not something we do today | 10:39:19 |
| Alyssa Ross | (across the board, at least) | 10:39:31 |
 infinisil | I'm still thinking just ripping the band-aid off with a single commit is probably easiest tbh :)
(and it is what's in the RFC fyi) | 10:39:36 |
 @piegames:matrix.org | hm, didn't know that | 10:39:39 |
| Alyssa Ross | you can look up the PR for a commit using the API / GitHub web anyway | 10:39:53 |
| Alyssa Ross | even if it was "Rebase and Merge"d | 10:39:58 |
| infinisil | Btw I created an RFC 140 milestone: https://github.com/NixOS/nixpkgs/milestone/25 | 10:41:47 |
| infinisil | Was a bit hard to keep track of all the PRs/issues | 10:42:21 |
 profpatsch | staging-next should probably just receive a separate formatting commit | 10:50:38 |
| profpatsch | At least in my mind formatting is deterministic, so no further merge conflicts | 10:51:03 |
| infinisil | (this isn't about formatting though) | 10:51:40 |
| infinisil | * (this isn't about formatting fyi) | 10:51:47 |
| profpatsch | oh, then disregard :) | 10:52:40 |
| profpatsch | I read “the automatic migration” and made an ass out of u & me | 10:53:05 |
| infinisil | Haha nah all good | 10:53:27 |
 teto | I watched the pkgs/by-name nix-con talk . At some point it was mentioned that package sets like haskellPackages / luaPackages were out of scope and I was curious if there was work started regarding those package sets (yet). I have some related questions such as "shall we keep everything in one generated.nix file or explode those in xx/PACKAGE/default.nix" | 11:15:07 |
| teto | one of my main problem is that one package that can't be updated (because wrong src etc) will block the generation of the whole package set. I have started working on a workaround with pytreesitter to replace AST nodes when successful but having per-package files has advantages (but I wonder if the sheer number of new files doesn't make it a no-go anyway) | 11:17:11 |
| infinisil | teto: No concrete plans yet. Quick thoughts regarding single vs multiple files: I think multiple files should be preferred regarding git, it should lead to a smaller repo size and make conflicts less frequent | 11:31:00 |
| infinisil |
Check pkgs/by-name / check (pull_request_target) Successful in 46s
Why does this check seem to take longer now 🙃
| 14:54:20 |
| infinisil | Oh damn, looks like the actions/checkout@v4 is slower: https://github.com/NixOS/nixpkgs/actions/runs/6160467816/job/16717506688?pr=254423 | 14:54:54 |
| infinisil | Or it could be https://github.com/NixOS/nixpkgs/pull/254371 | 14:58:35 |
| infinisil | Well whatever, it's still fast enough, not worth looking into | 14:58:50 |
| 13 Sep 2023 |
 @quantenzitrone:matrix.org | whoa there are already 37 new packages using pkgs/by-name | 16:11:37 |
| @quantenzitrone:matrix.org | * whoa there are already 36 new packages using pkgs/by-name | 16:12:05 |
| @quantenzitrone:matrix.org | oh no, some people are moving their packages over | 16:13:38 |
| infinisil | Quantenzitrone: Check out https://github.com/NixOS/nixpkgs/tree/master/pkgs/by-name#manual-migration-guidelines :) | 16:24:02 |
| infinisil | It's not bad if the code is being touched anyways | 16:24:26 |
| 14 Sep 2023 |
|  jlesquembre changed their display name from José Luis Lafuente to jlesquembre. | 10:36:42 |
 Robert Hensing (roberth) | In reply to @infinisil:matrix.org
teto: No concrete plans yet. Quick thoughts regarding single vs multiple files: I think multiple files should be preferred regarding git, it should lead to a smaller repo size and make conflicts less frequent Also if it's a locked fetchTree those small files may never be written to disk, so i/o doesn't have to be a concern if libgit2 is a good lib. Probably is | 11:01:14 |
| 15 Sep 2023 |
|  @sbc64:matrix.org set a profile picture. | 09:39:33 |
