| 11 Jun 2023 |
 Wanja Hentze | all I know is that nixpkgs is an absolute unit | 10:16:51 |
 @piegames:matrix.org | It's like the Matrix, you must have seen it for yourself | 10:16:58 |
| Wanja Hentze | we should resolve this like the Rust folks resolved the great async syntax debate and pick a choice that everyone hates equally | 10:19:23 |
| Wanja Hentze | let's just name it `.DS_Store` | 10:19:40 |
 K900 | Oof | 10:19:48 |
| @piegames:matrix.org | In reply to @whentze:matrix.org
let's just name it `.DS_Store` .nomedia | 10:20:10 |
| K900 | System Volume Information | 10:20:25 |
 @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 |
