| 11 Jun 2023 |
 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 |
| @piegames:matrix.org | Oh no I didn't mean that top level. I mean pkgs/unit or whatever as the top level | 10:48:30 |
| @piegames:matrix.org | so adding new folders to nixpkgs won't affect that | 10:48:45 |
| @syphoxy:matrix.org | right. that's why I made my suggestion. it scales and it eliminates the need for a concept we don't need. | 10:48:55 |
| @syphoxy:matrix.org | I fail to see how this is the combined disadvantages of other suggested solutions. | 10:49:35 |
| @piegames:matrix.org | I'll re-read it again then | 10:49:59 |
| @piegames:matrix.org | In reply to @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. And usually most software has no folder size limits, only slowly degrading performance (usually linearly). | 10:50:32 |
