| 10 Jul 2022 |
infinisil | In reply to @gytis-ivaskevicius:matrix.org
Hi all, yesterday this idea popped into my mind, has no business value just a cleanup. Maybe someone could evolve this idea further. Anyways here I go:
pkgs is a large complex recursive structure that should be simplified. Solution: Create several 'simple' namespaces which together could be evaluated to pkgs
One of the examples would be lib structure, while it contains basically anything - it is nice and flat lib :: attrsOf any
So off the top of my head, there are 2 that could be separated:
- Builders - functions that return derivation.
builders :: pkgs -> attrsOf (attrs -> derivation)
- Package groups - attribute sets of packages like
python.<derivation> or gnome.<derivation>. Sometimes they include builders, not sure how to deal with that. packageGroups :: pkgs -> attrsOf derivation
pkgs evaluation:
let
result = fancyPkgsBuilder [
(builders result)
(packageGroups result)
(rootPackages result)
];
in result
And yeah, for the record I have not thought all this through and there will be edge cases, just maybe if there ever is going to be some large refactoring someone will keep this in mind.
I haven't thought of making a separation like that, but it's an interesting thought. I guess this also goes a bit into the direction of what flakes does, to have separate output attributes for different things, like derivations in packages, library functions in lib, nixos modules in nixosModules, etc. | 15:01:20 |
kevincox | We kinda already have separation for a few things like lib and python packages. But to be honest I generally find that anything more complex leads to pretty meaningless grouping.
For example with the nixpkgs directory structure I always feel like I'm picking a vaguely related directory when adding a package and I've never actually got any value from the topic directory a package was in. In fact it is just annoying because the longer path makes false positives in my IDE's fuzzy finder. | 15:17:07 |
K900 | We should just do a crates.io and organize packages by name | 15:26:35 |
K900 | pkgs/h/he/hello/default.nix | 15:26:52 |
K900 | (no) | 15:26:54 |
K900 | (unless?) | 15:26:57 |
infinisil | I've wanted something like this for a while. I think it would be a good idea | 15:27:41 |
K900 | * `pkgs/h/e/hello/default.nix` | 15:27:59 |
K900 | The more I think about it, the more I'm starting to like it tbh | 15:28:16 |
K900 | It's kind of the same thing as having a consistent formatter (no. drop the pitchforks.) | 15:29:04 |
K900 | It's better to have a fixed convention than to argue about it every time | 15:29:24 |
Rick (Mindavi) | In reply to @k900:0upti.me It's better to have a fixed convention than to argue about it every time Yes, but indeed always hard to enforce/add retroactively | 15:30:30 |
infinisil | It should probably be pkgs/prefixed/h/e/hello/default.nix, so a slow transition is possible | 15:30:52 |
infinisil | Also I like the idea of introducing tags, like meta.tags = [ "gui" "audio" "networking" ], and then having some functions/tools to filter/search by category | 15:31:53 |
infinisil | This could replace the loose categories of the file path | 15:32:25 |
kevincox | Do we even need subdirectories. Is performance on any modern filesystem or git bad for big directories? | 15:33:15 |
kevincox | I guess it doesn't hurt to be safe? | 15:33:28 |
K900 | Github web UI still chokes at over 1000 files | 15:33:32 |
infinisil | Yeah I think this is a main reason | 15:33:41 |
K900 | Also, there's NTFS | 15:33:47 |
kevincox | But either way I am 100x more in favour of flat + tags over hierarchy. | 15:33:49 |
K900 | Which we might want to support at some point | 15:33:56 |
Alyssa Ross | git works badly with big flat directories too | 15:34:08 |
K900 | And which has no dentry cache | 15:34:09 |
Alyssa Ross | because you have to store the whole tree every time | 15:34:15 |
Alyssa Ross | whereas with two levels of prefix directories you have to store 1/26^2 of the tree every time | 15:34:36 |
K900 | Man I really wish I had the brain juice to push this sort of stuff | 15:34:55 |
K900 | I'd love to see it happen but it's so much coordination work and I'm already burned out as is | 15:35:48 |
kevincox | Well you store the while tree but 99% is the same as last time so it compresses just like any other blob with a 1-line change. | 15:35:49 |
infinisil | K900: This team should help with that :D | 15:36:20 |