| 11 Jun 2023 |
 @syphoxy:matrix.org | I have a question. why are there items in pkgs/ that aren't part of the sharding? | 10:20:40 |
 K900 | Because there's stuff like python-packages | 10:20:51 |
| K900 | That should probably live in its own directory | 10:21:02 |
 @piegames:matrix.org | Because some have a more complicated setup that can't be easily migrated | 10:21:12 |
 hexa | yeah, we have scripts working on the python-modules directory | 10:21:45 |
| hexa | would be bad if we had to rework that discovery process 😄 | 10:21:57 |
| @piegames:matrix.org | Same for gnomeExtensions | 10:22:01 |
| K900 | It would be cool to eventually end up with python-modules/by-name though | 10:22:06 |
| K900 | And similar in other sets | 10:22:10 |
| hexa | certainly | 10:22:17 |
| K900 | But we'll have to do that on a set by set basis I think | 10:22:32 |
| @piegames:matrix.org | I think that is mentioned in Future work | 10:22:43 |
| @syphoxy:matrix.org | how about this..
pkgs/A/B/${name}/package.nix
everything that isn't part of the sharding stays in pkgs/ like where it is now.
the one issue we came up with this is that short name packages become ambiguous but I'm pretty sure the ambiguous case only happens for 1 character package names. if you had a package "ab", that would result in pkgs/a/b/ab/package.nix.
for the single letter packages, which in the most generous of circumstances would be at most 40, we could special case them in a folder pkgs/root/. | 10:28:30 |
| @syphoxy:matrix.org | even if we wanted to expand the sharding out to 3 or 4 levels, the ambiguous case would always be the 1 character package names because the shard .. key? is only 1 character long. | 10:30:40 |
| @syphoxy:matrix.org | that is, at any level of the sharding, we can distinguish the shard path from a package because packages must be more than 1 character long in length. | 10:31:43 |
| @piegames:matrix.org | I think this combines the disadvantages of mixing shards with categories and multi-level sharding | 10:32:04 |
| @syphoxy:matrix.org | um. I don't follow. | 10:32:44 |
| @piegames:matrix.org | Both of these have been discussed individually and been rejected for various reasons. And combining them gives you the worst of both IMO | 10:33:26 |
| @syphoxy:matrix.org | isn't the prevailing solution that we want pkgs/AA/BB/..? | 10:34:11 |
| @piegames:matrix.org | no | 10:34:25 |
| @piegames:matrix.org | Basically the implicit constraints for the design space I've gathered so far from previous discussions are:
- No insanely huge folders (also no single flat folder)
- Works with short package names without too much complexity
- No special casing
- No mixing with "classic" structures
| 10:36:32 |
| @syphoxy:matrix.org | personally, I agree with those though I'm fairly certain the first is infeasible without introducing categories .. which apparently people are unhappy about. | 10:39:40 |
| @piegames:matrix.org | In reply to @syphoxy:matrix.org
personally, I agree with those though I'm fairly certain the first is infeasible without introducing categories .. which apparently people are unhappy about. Depends on the definition of huge. With the current proposal, we'll be under 1000 for most entries, same for the root level, and a bit over for li. See this thread also https://github.com/NixOS/rfcs/pull/140#discussion_r1212309795 | 10:40:57 |
| @syphoxy:matrix.org | the worst case scenario for that is 1600. | 10:42:09 |
| @syphoxy:matrix.org | we're already at 951 by those estimates. | 10:43:25 |
| @piegames:matrix.org | For the top level? Yeah but that one is bounded because it's a finite set, I don't expect it to grow much more than that | 10:45:07 |
| @syphoxy:matrix.org | yeah but .. that implies we're already creating a bad user experience. | 10:46:06 |
| @piegames:matrix.org | Um, why? | 10:46:43 |
| @syphoxy:matrix.org | the limit is 1000 for GitHub. who knows what it is for whatever UIs people are using. there are other items in pkgs/ as well. every time something enters pkgs/ we that much closer to hitting the limit again. | 10:47:41 |
| @syphoxy:matrix.org | I don't see a point in overhauling the entire ecosystem if the issue needs to be revisited as soon as NixOS gets larger. | 10:48:14 |
