The notion that the multiple config classes in a project is extreme and rare is wrong. PC users are swarming to Linux and PC Linux users are adopting combinations of NixOS, home-manager, nix-darwin, nixvim and more, daily.
They need to reason about their implementations with a minimal and consistent overhead. The dendritic pattern provides that like nothing else does.
Also, it’s not a framework. It’s just a pattern.
The notion that the multiple config classes in a project is extreme and rare is wrong.
i don’t think i get this part and if you are referring to nixos/darwin/hm/etc. classes in a repo, i don’t think it’s wrong at all? if whoever is writing the code can clearly distinguish the difference between it’d be all good (which is one of the reason why i don’t really like the dendritic pattern bc everything is “squashed” into flake parts modules and i can’t easily tell which file is for what just based on the directory stucture)
PC users are swarming to Linux and PC Linux users are adopting combinations of NixOS, home-manager, nix-darwin, nixvim and more, daily.
im guilty of converting almost everyone in my office to nixos. for new users, i always remind them to think of a good “system” to separate which is which and for what part of the config, e.g.
nixos, nix-darwin for os level entry
hm for user level stuff but you can import them as a part of the os config
nixvim, and emacs config management framework, they should be put under pkgs/ and bring in as overlay (for nixvim it would be calling makeNixvimWithModule)
everything are then put into respective “config class” directory, which i think provides
a minimal and consistent overhead
But they’re not
Not either
Yes, and that’s one of the reasons everybody is advertising “just put everything in package.nix files, and make flake.nix a single callPackage statement”.
That’s one example of “metadata” that we want to be “static”, i.e. accessible without nix evaluation, but yes.
There wasn’t anything new that was built, it’s literally just “look, flake-parts, that’s a cool application for evalModules, let’s use flake-parts and call that dendritic”
ok now colmena is also dendritic
there’s nothing over-engineered, because there’s no “pattern”, unless “use evalModules for stuff” is the pattern, which would be fine
Yeah well it is “standard”, because it’s literally what NixOS does, what home-manager does, what colmena does, what flake-parts do… there’s just no reason to mystify this stuff.
I respectfully disagree that there’s ‘no pattern’, though I feel that the pattern is something common across programming composition in general and not unique to nix. When applied well, you get nice structure like this. If you’re just importing everything and config gating, that’s a valid pattern too – but doesn’t resonate for me personally.
Completely agree. I think the translator mishandled some issues with tone and vocabulary. Sorry for causing ambiguity.
Yes, it really doesn’t. Actually, what I mean is:
“Flakes was originally intended to be a solution → but in reality we know it didn’t achieve that → so in my opinion, at most it can be considered a compromise product.”
Yes, this is just one way to use evalModules, not something new. I guess I shouldn’t use ‘Built’ here?
Thank you for taking the time to read and correct my mistakes