| 12 Sep 2023 |
 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 |
| 19 Sep 2023 |
 @alejandrosame:matrix.org | I extracted the code that makes pkgs/by-name to a separate repo to experiment with it. Something that I noticed is that lib is passed as a hardcoded relative path. Has there any thought been given to make the by-name a reusable pattern? Maybe making sharding optional (as it makes sense for big package repos like nixpkgs but not smaller repos). | 13:20:05 |
| @alejandrosame:matrix.org | * I extracted the code that makes pkgs/by-name work to a separate repo to experiment with it. Something that I noticed is that lib is passed as a hardcoded relative path. Has there any thought been given to make the by-name a reusable pattern? Maybe making sharding optional (as it makes sense for big package repos like nixpkgs but not smaller repos). | 13:20:18 |
| infinisil | alejandrosame: I would like it to be stabilised and re-usable for third-parties in the future, but only after RFC 140 is fully implemented, including the migration. Mainly to see if any problems come up, in which case we can fix them first without worrying about third-party uses | 14:02:32 |
| @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 |
