Example of cross-cutting concern in a single flake-module.

[vic]

Hey @mightyiam, thanks for creating the dendritic pattern and this repo dedicated to it.

I'm thinking on adding a bit more of documentation about why this pattern is useful, perhaps some code, not intended to be actually used, but more on the lines of an example of cross-cutting concerns (or a feature) across different nix module classes, and how the dendritic approach allows grouping these different module classes by their single purpose.

I was thinking something along these lines (pseudo-code not tested):

# /modules/features/example.nix
{ inputs, lib, config, ... }:
let

  #  a custom package is defined (suppose this package has some os-level requirement, like firewall rules or any other os config requirement)
  perSystem = { pkgs, ...}: {
      packages.example = pkgs.mkDerivation {
         src = inputs.example-program-src; 
     };
  };

  #   - nixos, darwin modules provide os-level configurations 
  flake.modules.nixos."feature/example" = {
       # a nixos systemd unit or some other os-level conf
  };

  flake.modules.darwin."feature/example" = {
       # a darwin launch agent or some other os-level conf
  };

  #  - homeManager module that adds the package to an user environment and ~/.config for it to work
  flake.modules.homeManager."feature/example" = {pkgs, ...}: {
     # things like shell-aliases, shell-completion and other home-level behaviour for this feature.
     home.packages = [ inputs.self.packages.${pkgs.system}.example ];
     home.file.".config/example/settings".text = "port = ${conf.port}";
  };

  conf = config.features.example;
  opts.feature.example.enable = lib.mkEnableOption "Example feature";
  opts.feature.example.port = lib.mkOption {
     type = lib.types.port;
     default = 12345;
  };

in 
{
  options = opts;
  config = lib.mkIf conf.enable  { inherit flake perSystem; };
}

of course it does not have to be about firewall rules, any other os-level example should work, I want to illustrate how the flake-parts module can expose an option that enables (and exposes functionality) across os/home/flake levels.

any input on this idea is more than welcome :)

[vic]

And then applying that feature to nixos/darwin/homeManager configurations (or even into other enclosing features/cross-cutting concerns)

# /modules/hosts/myhost.nix
{ inputs, lib, config, ... }:
let
  # this could be an specific host `myhost` or just a bigger, containing concern: `laptop`, `desktop`.
  flake.modules.nixos.myhost.imports = 
    lib.map (feature "nixos") [ "example" "vpn" "secrets" ];  # vpn, secrets are other features
  
  # same here, either specific user or another bigger concern.
  flake.modules.homeManager.myuser.imports =
    lib.map (feature "homeManager") [ "example" "vpn" "secrets" ];

  # produces a module that gets included only if the named feature is enabled.
  # this could be part of dendritic.lib or something.
  feature = class: name: lib.mkIf config.features.${name}.enable {
     imports = [ inputs.self.modules.${class}."feature/${name}" ];
  };
in
{
   inherit flake;
}

[vic]

Maybe we could just start by a simpler version of this where no enable option is involved ? dunno. Cool thing is that dendritic enables having options at a higher level than flake/nixos/darwin/homeManager, enabling a dendritic option produces configuration on all those layers.

What you think ?

[vic]

Read also: drupol/not-a-number.io#30 (reply in thread)

[mightyiam]

General 👍 on this. But with the time I had today I figured I best cover some basics. So I made #2. Will reach this matter eventually and take a close look at your input then.

[drupol]

This issue has been implemented in the very lightweight Unify flake.parts module: https://codeberg.org/quasigod/unify/

I have rewritten my config (once again!) at drupol/infra#84, luckily, it took me only 15 minutes, it was just a matter of renaming and moving files.

Initially I didn't want to use an external flake.parts module, but after reviewing the Unify framework, I noticed that it was doing (in a much better way) what I was already doing manually in my repo, so I tried it and I have to admit that this is even better now. This is a real and valid implementation of cross-cutting concerns, made perfectly.

[vic]

Hey @drupol,

This issue was more about providing an documented example of a single concern crossing different nix module classes, so that people can get a better feel about what the dendritic pattern is about. I highlight pattern, since the example is intended to shine some light on the way of thinking -on cross cutting concerns- instead of how actually things get glued: @mightyiam glue code, mine or Unify's. that means that maybe we have currently at least three different Dendritic implementations (because it is more a way of thinking nix configs)

Maybe it was my bad to include an .enable option in the example code. As I mentioned on this issue before, perhaps the cross-cutting concern example does not need having an enable option to prove the value of the Dendritic pattern. I just added it because it was cool to me that having an option enabled or disabled exposing a package and whole modules on the flake.

That said, the rest of this comment might be off-topic, and more about how I feel at Unify, and would love @michaelBelsanti take on this.

Last time i checked Unify I liked some of it and disliked some other parts at the same time. Don't get me wrong, I feel it is definitely a move in the right direction, but here are some reasons (taste or personal reasons perhaps) on why I'm still using just pure flake-parts and still see no need for another lib (til I feel compelled to it):

I loved the idea of having modules at unify.hosts.myhost.nixos instead of flake.modules.nixos.myhost.

I mean, at first it might seem like xyz.nixos instead of nixos.xyz is a meaningless shift, but :

unify.hosts.myhost = {
   nixos = {config, ...}: {
      # a nixos class module
   };
   darwin = {config, ...}: {
     # a nix-darwin class module
   }
   # foo = {}; // it should be possible to have any other `foo` class module that might be configured in the `myhost` concern.
}

Having different kinds of module classes inside the "cross-cutting concern" feels right to me, and true to the dendritic pattern.

However I'd rename this unify.hosts.myhost to unify.feature.myhost (picked feature but could be modules or anything else that is not necessarily hosts, since not all nix modules are host specific - like homeManager configs)

While still allowing to expose flake.nixosConfigurations (and darwins - I also have a few darwin hosts and Unify is still pending darwin support last I checked)

# currently it is `unify.host` and am still not sure how will Unify support darwin hosts or other types of flake exposed configurations.  
unify.nixos.myhost.tags = [ "xyz" ]  # let it include the from `unify.feature.xyz.nixos`
unify.darwin.myhost.tags = [ "xyz" ] # same hostname but different OS

Dunno, I'm not even sure I like what I have written here, haha.

Because it seems to me like (my bad proposal above) and Unify tags are just another way to write flake.nixosConfigurations.foo.includes = [..] and flake.darwinConfigurations.foo.includes = [..], just like I do already

That's why I'm still using just flake-parts and still see the need for nothing else.

So, while I love the idea of having different nix module classes grouped inside a single unify.feature.xyz, I'm still not sure I need a lib to generate nixosConfigurations for me and having to wait for it to support darwin or standalone homes, not-single-user hosts, or anything that I already need for my configs.

I personally, really like having a single file (my osConfigurations.nix touched when I add/disable a flake os configuration output, while all other files are just about exposing modules of different classes.

I also don't feel like I want my nixos modules automatically be exposed as nixosConfigurations just because my nixos modules exist.

For example, if I have many (many) files exposing flake.modules.nixos.foo that doesn't mean I need a flake.nixosConfigurations.foo, that's why for example, @mightyiam has flake.modules.nixos."nixosConfigurations/foo" from which flake.nixosConfigurations are actually exposed.

Anyways I'm still quite comfortable with having a single place for exposing my os configs. And the rest of my files just expose modules of different classes.

If @mightyiam glue code or mine were exposed as a framework, people would have to wait for such a framework to also support darwinConfigurations or multiple-users or anything else. Maybe I'd be more in line with having a dendritic lib utility functions that can be mixed according to how people actually prefer to do things, more than a framework (like rails conventions). That's why I think Dendritic is currently pattern, you can implement it in many different ways without having to be tied to moving my configurations to yet another attribute set.

Maybe as we all explore our different Dendritic implementations, we can get a better idea if it is worth for this repo to have a Dendritic lib or flake-modules (or be it Unify). Or if dendritic as a pattern requires no code at all and serve just to clarify its advantages and way of thinking and maybe just a pure flake-parts template to get people started quickly with it.

[vic]

Quick questions for @mightyiam. Perhaps you haven't had the need for this, but suppose I have many .nix files in my tree that expose flake.modules.nixos."nixosConfigurations/foo", if suddenly I needed to disable or temporarily decomission a host, how would you do it ? I'm guessing you have such a module in just a single file and it includes other nixos configs itself, so that disabling is just commenting on a single file, right ?

[vic]

One thing I love about the Dendritic pattern, is that it would allow for us to create other repos with different "configurations" distributions, like people do for different vim/emacs distributions.

NixOS for security oriented ops, NixOS for Gaming, NixOS for AI coding, etc, and freely mix up these on your own nixos configs.

By exposing flake-modules that are just configurations of some features (no conventions regarding how to name your nixos modules, where to place your configs, just a flakeModule to include on yours to get whole OS shiny configurations).

But such configuration distributions might be in other repos as well.

[mightyiam]

Quick questions for @mightyiam. Perhaps you haven't had the need for this, but suppose I have many .nix files in my tree that expose flake.modules.nixos."nixosConfigurations/foo", if suddenly I needed to disable or temporarily decomission a host, how would you do it ? I'm guessing you have such a module in just a single file and it includes other nixos configs itself, so that disabling is just commenting on a single file, right ?

Dynamic nature of this language makes refactoring more tedious than in languages with more static features. I kind of accept this and don't make much effort to regain this. To answer your question concretely, I do have multiple files with nixosConfigurations/<name> and each set of them is in its own directory:

https://github.com/mightyiam/infra/tree/46c1de3c6cdca832b1d40a1fe71080980ed432a8/modules/ganoderma
https://github.com/mightyiam/infra/tree/46c1de3c6cdca832b1d40a1fe71080980ed432a8/modules/termitomyces

To disable any of these I would prefix the directory with _.

[michaelBelsanti]

However I'd rename this unify.hosts.myhost to unify.feature.myhost (picked feature but could be modules or anything else that is not necessarily hosts, since not all nix modules are host specific - like homeManager configs)

I could be misunderstanding, but Unify does have an option for non host specific modules under unify.modules.featurename.{nixos,home} which is applied if the feature name is defined in the hosts tags. Like you said, it is pretty much the same as importing based on the feature name. I just preferred the syntax of using a list of strings, as this list could be reused for other tools that use a similar option, like Colmena.

I mean, at first it might seem like xyz.nixos instead of nixos.xyz is a meaningless shift, but

That change is syntax is pretty much the main reason I made Unify, so I 100% agree here!

I definitely understand what you mean about it basically just doing the same stuff as what your glue code is already doing. I did recently update unify to export NixOS and home-manager modules under the expected modules, so if somebody (understandably) wasn't a fan of how unify does host, they could still utilize the way unify declared modules and import them the same way they would in a more proper dendritic pattern implementation, and hopefully I could make more changes to make Unify more flexible.

I don't really expect Unify to be a perfect option for the Dendritic pattern, but I am glad that it could create some discussion about what the best way to implement the pattern could be! Unify was really more inspired by Denix than anything else, but I wanted to find a way to simplify its implementation, and the "every file is a flake-parts module" was a great way of doing it.

Your comment gave me a lot to consider that I hadn't thought about yet, thank you!

(sorry if this reply is a mess I kept getting interrupted while writing it and forgetting what I was trying to say lol)

[vic]

One thing I love about the Dendritic pattern, is that it would allow for us to create other repos with different "configurations" distributions, like people do for different vim/emacs distributions.

NixOS for security oriented ops, NixOS for Gaming, NixOS for AI coding, etc, and freely mix up these on your own nixos configs.

By exposing flake-modules that are just configurations of some features (no conventions regarding how to name your nixos modules, where to place your configs, just a flakeModule to include on yours to get whole OS shiny configurations).

But such configuration distributions might be in other repos as well.

<off-topic>
Following on this idea of mine, I've started a repo Dennix. I'll be extracting generic (non-host specific nor user-specific) configurations from my vix repository. I'll start with something basic (kde/gnome/xfce basic rices I have on my setup) and create a basic template and instruction on how to include dennix layers (exposed flake-parts modules loaded from different sub-directories by import-tree). but I'd love to later have some more specialized configurations (like AIs (like @drupol's) or Gaming (perhaps @mightyiam's Steam configs) as long as they are ok with sharing some of it. Anyways, its a first start on a dendritic-based configurations distribution.
</off-topic>

[dtomvan]

I guess this new module of mine could be close to a nice example of a cross-cutting concern between NixOS and home-manager. It currently configures:

• NixOS fonts.*
• KDE Plasma fonts kcm
• Konsole
• Kate
• Alacritty (or rather, my generic terminals module, where I can choose which ones I want installed but they have some shared configs)

... so that they all get Inter as sans-serif font, and afio 12 as monospace font.

[mightyiam]

I will keep apologizing for not having made progress on this. Been refining https://github.com/mightyiam/input-branches because "my priorities" but I'm following all input and want to get to this soon enough.

[Yeshey]

I'm basically waiting for an example on this repo to decide if I want to refactor my config ahaha

[panchoh]

I'm basically waiting for an example on this repo to decide if I want to refactor my config ahaha

For a taste, try Vic’s. It's just beautiful.