Dendritic community and sharing modules subtrees

[vic]

TL;DR. Proposal: Add to README a Dendritic Community Recommendation: Have a ./modules/community directory.

I love the fact that the dendritic pattern allows us to have "incremental features".
Something we may even have to document as another advantage of the pattern.

By this I mean, that a single file feature-a.nix in a repository can define packages and configure
different module classes (as any flake-parts module). However, the fact
that this cross-cutting configuration is possible, enables us to potentially
share a well defined feature-a with the community, while also allowing the very same source repository
to extend it for the author's particular infra needs. Because, in the dendritic pattern,
we can have as many files inside our import-tree loaded directory, to increment the feature
originally defined by the first feature-a.nix file.

Now, given that most of us already have a ./modules directory from where we import
all our .nix files, we could easily have the following

Dendritic Community Recommendation: To have a ./modules/community subdirectory.

This would not affect any of us functionally, since anyways we already load all of ./modules
and one of the Dendritic unique advantages is that you can move/rename your files freely.
However, having a community sub-tree would allows to move there features that are generic
enough and stable (since we are already using them in our infra) to be provided for others.

How you organize files inside ./modules/community is still up to your hearts content.
But some community conventions could arise in the future from people willing
to be part of something bigger than our individual infra repos.

This way, we could have a repo to be something akin to nix-community/NUR:
A registry of repos willing to share ./modules/community dendritic configurations from
which people can easily pick subtrees:

This dendritic-community flake would be just something like:

{
    inputs = {
      vix.url = "github:vic/vix?subdir=modules/community";
      vix.flake = false; # since its just a path of shared modules, not a flake itself.

      # more community contributions here.
    };

    outputs = inputs: builtins.removeAttrs inputs ["self"];
}

# on someone's flake
import-tree [
  ./modules # that person modules

  inputs.dendritic-community.vix # path that could be import-tree.filtered further.
];

But, why not simply let people reuse our flake.modules.nixos.feature-a modules,
since they are already defined on our flakes?

Yes, that is already possible and also that's why module outputs exist on flakes (to be reused).
However, I see three disadvantages to using flake outputs instead of simply a directory convention:

The first is that there's no convention on how we name our modules (and that's a good thing,
because it allows us to think of the features in our repo as we see fit - eg, some of these modules
are my actual hosts tied to some particular hardware/etc).
I believe a naming convention might araise and only makes sense for things under ./modules/community.

Second is that a flake output module is the aggregation of all configs that contribute to the same feature (including the ones particular to my infra hardware).

The third is that if we use a flake output we have to evaluate the flake, and download all the flake inputs.
The dendritic-community repository would make more sense if it only exposes trees of configs.
(using ?subtree=modules/community as in the example above), otherwise we would be better just
directly adding inputs on user flakes (and dealing with inputs.follows and _dedup)

Imagine that someone wants to load vic's jujutsu/git/wezterm configs without having to
download all the inputs of their flake. If I do need something from vix/community that expects
an input, I'd provide it on my flake. (Is this an anti-pattern on flake.parts?: do not make assumptions about inputs)

[vic]

Did that on my repo vix#137, just moved some files into ./modules/community and everything still works :).

Now I'll change how vic/dennix works (to be more in line with something akin to NUR).

This is great, because previously I was thinking (and even started) moving some of my re-usable nix files into vic/dennix.
However now I don't have to do that to contribute to the community, I keep my nix files in my repo, and still opt-in to share some of them.

[mightyiam]

This repo serves to document a pattern. I'd like to see where your experiment goes, but I would say making such a recommendation here out of scope.

[vic]

I agree, that's why I referred to it as a "recommendation".

Anyways, we don't even need that ./modules/community recommendation on this repo. The README on Dennix repo now explains how to add dendritic repos even if we don't have an directory structure convention. And this is a good thing, that dendritic does not force any naming convention. :)