Dendrix - community-driven distribution of Dendritic Nix configurations.#

Editor-distributions like those for nvim/emacs provide community-driven, opinionated configurations that can be easily reused and enabled by newcomers.

The dendrix project aims to provide the same experience: having community-managed, high-quality and no-barrier-of-entry setups for everything that can be configured using flake-parts modules.

Read more on Motivation and How it works.

Available dendritic repos.#

The following is a list of known dendritic repositories from the nix community. If you want to add/remove one of them, send a pull-request that edits dev/npins/sources.json. Also if you want to provide custom trees, send a pull-request editing dev/modules/community/your_repo.nix.

# usage on your layers.nix
{inputs, ...}: {
  imports = [
    inputs.dendrix.community.Maka-77x-nixconf7.default
  ];
}

# usage on your layers.nix
{inputs, ...}: {
  imports = [
    inputs.dendrix.community.dliberalesso-nix-config.default
  ];
}

# usage on your layers.nix
{inputs, ...}: {
  imports = [
    inputs.dendrix.community.drupol-infra.default
  ];
}

# usage on your layers.nix
{inputs, ...}: {
  imports = [
    inputs.dendrix.community.gaetanlepage-nix-config.default
  ];
}

# usage on your layers.nix
{inputs, ...}: {
  imports = [
    inputs.dendrix.community.henrysipp-nix-setup.default
  ];
}

# usage on your layers.nix
{inputs, ...}: {
  imports = [
    inputs.dendrix.community.icyd-nixvim.default
  ];
}

# usage on your layers.nix
{inputs, ...}: {
  imports = [
    inputs.dendrix.community.quasigod-nixconfig.default
  ];
}

# usage on your layers.nix
{inputs, ...}: {
  imports = [
    inputs.dendrix.community.vic-vix.default
  ];
}

# usage on your layers.nix
{inputs, ...}: {
  imports = [
    inputs.dendrix.community.vic-vix.vic
  ];
}

Cross-repository Dendritic Aspects.#

A primary advantage of the nix dendritic pattern are aspects (aka. cross-cutting concerns). If you browse the list of available repos above, you can see the aspects that each repo defines as discovered by Dendrix.

# virtualization.nix
{
  flake.modules.nixos.virtualization = { ... };
  flake.modules.darwin.virtualization = { ... };
  flake.modules.homeManager.virtualization = { ... };
}

The following is a list of aspects that are common in more than a single repository. Our hope is that people can collaborate to find naming conventions for common aspects. Having that we could mix configurations from different sources to enhance the same aspect.

Flags#

Flags are a dendrix convention used as part of a file or directory name as named signals. Flags only exist in positive form: +flag. A negative -flag means: ignore positive +flag files.

For example, if you have ai+local.nix and ai+cloud.nix files. The aspect configured by these files is most likely ai but the local and cloud flags signal the vendor.

Flags are inspired by editor configurations, like doomemacs: (scala +lsp). And are used in Dendrix only as a way to filter files on community import-trees. For example, one could exclude all +emacs paths like tree.flagged "-emacs +vim".

Quick Start#

We provide some templates you can use to start a new flake.

nix flake init github:vic/dendrix#template

Then edit your layers.nix file.

Try it Online!#

If you are not currently a NixOS user, you can try running an ephemereal NixOS on the web.

• Go to Distrosea nixos-unstable-minimal

Start a machine and run the following:

nix run .#os-switch template

Customization#

Once you have a ./modules/ directory on your flake, just add flake-parts modules following the dendritic pattern. All files will be loaded automatically. Edit your layers.nix to include dendrix provided aspects you choose.

Motivation#

shared-tree = import-tree.filter (lib.hasInfix "minimal");

shared-tree = import-tree.filterNot (lib.hasInfix "private");

shared-tree = import-tree.filter (lib.hasInfix "community");

# provider's flake
flake.lib.shared-tree = lib.pipe inputs.import-tree [
  (self: self.addPath ./modules)
  (self: self.filterNot lib.hasInfix("private"))
  (self: self.filter lib.hasInfix("community"))
  (self: self.addAPI {
    aspect-a = self: self.filter lib.hasInfix("A_aspect");
    aspect-b = self: self.filter lib.hasInfix("B_aspect");
    minimal = self: self.filter lib.hasInfix("minimal");
    maximal = self: self.filter lib.hasInfix("maximal");
  })
];

# consumer's flake
imports = [
  inputs.providers-flake.lib.shared-tree.minimal.aspect-a
  inputs.providers-flake.lib.shared-tree.maximal.aspect-b
];

How it works#

FAQ#

• Are these configurations restriced to dendritic setups?

  Yes. The reason is that using dendritic patterns allows us to easily combine configs from many different community sources knowing that each and every .nix file will be a flake-parts module.

  Layers (blessed presets) are always loaded by import-tree, but only enabled when you include them as part of a top-level module of yours.

• Is dendrix a NixOS based distribution ?

  In a way, but we still don't provide customized bootable installers.

  It is more a flake-parts configurations collection that can be included on any dendritic setup.

• Can I contribute my awesome Desktop rice?

  Sure! the best way to do that is to keep your desktop rice on your own repository. And use this repo to add an import-tree object pointing to it. See the notes above about contributing on dev/npins/sources.json and dev/modules/community/*.nix.

• How are layers made?

  A layer is a blessed dendritic setup, aimed to reuse aspects from the community provided dendritic repositories. However these blessed configs might have conventions that community repositories not necessarily follow (since our repos are mainly used for our own infra). So it is part of this community to create discussions about how to name things so that best practices and conventions arise around sharing and extending known aspects.

  For example, if we had a gaming aspect. We would need conventions on how to name aspect modules for gaming. And people would likely provide such dendritic configurations on their setups.

  So, long story short, layers are community owned setups. And repos are owned by a respective community member.

• How about Games/AI/Devops/Security layers?

  You are right on point!, that's precisely why this project started. We also want to provide specialized versions of NixOS focused on pre-configured security, gaming, development setups.

Contributing#

Since we all now have agreed to follow the Dendritic pattern to organize our files, lets take a few more guidelines to make eveybody's life easier:

• Always be nice, and have respect for others.
• Be professional and considerate we are giving our time and energy on this project as an invaluable good for others.
• Contributions are welcome as long as you also make a compromise to become maintainer for your aspect don't abandon your contribution easily. (Unmaintained files will be removed.)
• This is a community project, so as soon as your PR is merged you'll also get commit bit, however we restrict changes to be only via PRs and require code-owners review before merge.
• Prefer linear git history, squash PRs and no merge-commit. Vic recommends working with jujutsu.

Development#

We recommend to use direnv or anything that can load our nix develop path:dev environment. If you are using direnv, we provide an .envrc for it.

Upon entering the shell, you will see a menu of useful commands during development.

nix develop ./dev -c files # generate nix-controlled files (like this README) and format them.
nix flake check ./dev      # checks all is up-to-date, community checks, and formatting

# when adding a new repo, run npins inside of ./dev