In reply to @k900:0upti.me
But was pkgs/simple proposed?

In reply to @hexa:lossy.network
so at this time the RFC prefers a meaningless name over one with a meaning

In reply to @niksnut:matrix.org
infinisil: The RFC process doesn't replace PR review. And "pkgs/unit" shouldn't get through PR review.

I'm not sure if the peanut gallery is allowed to suggest things, I will promptly delete my message if not, but would pkgs/_XX be a sufficient compromise to the pkgs/unit/XX debacle? that is, any 3 character directory starting with an underscore is considered to be a shard. the underscore would give off the feeling of being an internal data structure as well, which would bring in the nuance that someone suggested with "auto." it would also be lexically grouped together in this way.

sorry in advance if I'm overstepping my bounds here.

I'm not sure if the peanut gallery is allowed to suggest things, I will promptly delete my message if not, but would pkgs/_XX be a sufficient compromise to the pkgs/unit/XX debacle? that is, any 3 character directory starting with an underscore is considered to be a shard. the underscore would give off the feeling of being an internal data structure as well, which would bring in the nuance that someone suggested with "auto." it would also be lexically grouped together in this way.

(strictly speaking, I find the idea of sharding for the sake of the GitHub UI to be unfortunate. I think it's weird that we're tying NixOS's design to GitHub's UX.)

sorry in advance if I'm overstepping my bounds here.

sy: Interesting idea, I can see some minor problems with it:

• Due to _ being listed before the alphabet, it would cause all the pkgs/top-level, pkgs/stdenv, etc. to be moved to the bottom of the file listing
• File structures of repos should be considered internal by default, so a _ could be interpreted as something that's even more internal, something that even developers of the repo shouldn't touch, maybe a bit exaggerated though

those are excellent points. I don't personally have anything to add to that but I do agree they are minor.

if we had to go the subdirectory route, I would vote on "shards" or "sharded" though I have very little interest in contributing to the naming discussion more than I already have.

(I am avoiding pkgs/unit here or pkgs/shards not as a statement but to focus the sharding structure.) regarding GitHub's UI, my only potentially naive rumination on the directory structure is that something like pkgs/A/B/${name}/package.nix or pkgs/A/B/C/${name}/packages.nix could be adopted instead of pkgs/AB/${name}/packages.nix or pkgs/AB/CD/${name}/packages.nix. having one letter levels would enforce that each level has a maximum of 26 directories. GitHub could surely be agreeable to that experience. given that there's a very large group of packages with the lib prefix it might even be appealing to have pkgs/A/B/C/D/${name}/package.nix

those are excellent points. I don't personally have anything to add to that but I do agree they are minor.

if we had to go the subdirectory route, I would vote on "shards" or "sharded" though I have very little interest in contributing to the naming discussion more than I already have.

(I am avoiding pkgs/unit here or pkgs/shards not as a statement but to focus the sharding structure.) regarding GitHub's UI, my only potentially naive rumination on the directory structure is that something like pkgs/A/B/${name}/package.nix or pkgs/A/B/C/${name}/packages.nix could be adopted instead of pkgs/AB/${name}/packages.nix or pkgs/AB/CD/${name}/packages.nix. having one letter levels would enforce that each level has a maximum of 26+10+2 directories. GitHub could surely be agreeable to that experience. given that there's a very large group of packages with the lib prefix it might even be appealing to have pkgs/A/B/C/D/${name}/package.nix