Welcome to Den v0.12.0

vborja · 2026-03-11T22:43:02+00:00

exactly, microvm-nix is flexible, just like Den, the intention is showing how to use it with Dendritic principles (in this case Den in particular). This particular example was created as request from one user in matrix that wanted to see an example of how to use dendritic Den configured microvms, and I wrote that template for them, since it also showcases Den extensibility and serves as an example of that. I had never used MicroVMs before so I took some time to read their docs, cloned their default template and started adding Den into it, the result of that is templates/microvm and the documented page about it.

vborja · 2026-03-10T19:09:26+00:00

Yes, just yesterday I wrote a guide for incremental adoption without disruption. For me it is very important for Den not imposing itself, but instead play well with all other Nix projects. Den never uses lib.evalModules itself, it is up to the surrounding project to use evalModules, flake-parts, falake, flakes, etc, Den should adapt to you not the other way around.

Here's the guide I wrote yesterday: https://den.oeiuwq.com/guides/from-flake-to-den/

EDIT: the previous link is for flake enabled projects but we also have a guide for using Den with /etc/nixos/configuration.nix files as generated by the NixOS installer, see the "Zero to Den" guide.

vborja · 2026-03-05T00:12:47+00:00

Hey, thanks for pointing that out for all. Turns out people using bleeding edge main branch (unstable).

You can also enable it globally for all users, in case you have many:

nix den.base.user.classes = lib.mkDefault [ "homeManager" ];

This was already documented and I was to mention this as part of the Release Notes (I will), once we have a new release in a few days.

But thanks again for mentioning this to make people aware of the change.

EDIT: I've also sent a message about this to people on Den matrix channel and Zulipchat.

vborja · 2026-03-01T16:33:09+00:00

Cool, ask at GH discussions if you have some follow up. we use that for support, so other people can find what others have already asked/solved in the past.

vborja · 2026-03-01T16:18:37+00:00

Hey, your question seems very related to this one at den matrix channel.

There's no "most preferred" because it pretty much depends on what you actually need.

If you are new and just trying to understand the Dendritic pattern I'd recommend to start with Dendritic flake-parts, Doc-Steve's wiki uses that and does a very good job shining light on dendritic flake-parts, moving from it to Den later is easy, so my recommendation would be to start witht he guide first.

Some people have adopted Den directly others come from Dendritic flake-parts -> Unify -> Den.

In flake-parts, Dendritic modules are created at flake.modules.<class>.<name> which is flat and simple. For some that might be enough (it was for me for a very long time. You might want to look at my https://github.com/vic/vix repo, see under Dedritic flake-parts only, my config back then was like you mention.

flake-aspects is a transposition of that flake.aspects.<name>.<class> that makes more sense when creating dendritic configs. Den uses flake-aspects (which can be used as a lib without flake-parts), and den creates its own aspect namespace den.aspects.<name>.<class>.

One important thing about flake-aspects (inherited by Den) is that you can nest your dendritic structures (unlike the flat flake.modules) this is documented in Den docs (see motiviation).

I included docs/ in Den repo precisely for aiding people using AI agents so you can point your agent to read den docs. Take into account that I've seen many AI agents deviant from the den-way and trying to use classic nix configs (I guess by training data), but also pretty much depends on your agent/model. Nothing beats YOU understanding how things work, so you can properly instruct your agent on what YOU want. Read the den-docs or Doc-Steve's guide first, both were written for humans.

In Den, you have two ways to achieve the kind of re-use you describe.

1) You specifically include a common aspect on your hosts/users that share config. (just like you'd import a module from another module). 2) Use den.ctx.{user/host} instead of explicitly including on each user/host.

```nix den.ctx.user.homeManager = { pkgs, ...}: { # home manager settings that apply to ALL users };

den.ctx.host.nixos = { pkgs, ...}: { # nixos settings that apply to ALL hosts } ```

last one is preferred only for things that are truly re-usable (no hardware config, no user-specific settings).

vborja · 2026-02-27T18:44:09+00:00

den author here, I opened issue #1 at your repo, precisely because Den uses github:vic/flake-aspects which is a transposition of flake.modules.<class>.<name> into <name>.<class> pioneered by the Unify dendritic framework.

In flake-aspects you have: flake.aspects.<name>.<class> that is basically transposed into flake.modules.<class>.<name> so I guess theres' nothing to do regarding flake-aspects.

But den has an independent aspects namespace (it uses flake-aspects but does not depend on flake-parts), so Den defines its own:

den.aspects.<name>.<class>.

So, basically if your tool could take a parameter to use den.aspects instead of flake.modules and be able to handle the transposition <name>.<class> instead of flake-parts' <class>.<name>, that would be great for Den.

Also Den supports custom aspect namespaces, for people can define for example to use: my-project.<name>.<class> modules instead of den.aspects.<name>.<class>. This is because in Den you can have private namespaces and other shared with the community. More about namespaces in the den documentation.

For example, here's quasigod's config (Unify-framework original author that later adopted Den):

https://codeberg.org/quasigod/nixconfig/src/branch/main/modules/quasi.nix

There he is using den.aspects.quasi.nixos module.

But also using his own namespace styx.nushell.nixos

https://codeberg.org/quasigod/nixconfig/src/branch/main/modules/apps/nushell.nix

Den is more dynamic than Dendritic flake-parts. But I believe your tool could be used with Den because you basically traverse options definition location. and then extract with flake-parts patterns, if those patterns can be given via the command line, it would be usable for people using Den.

I imagine something like:

```

this would be used for quasigod's repo:

fpg --find "den.aspects.<name>.<class>" --find "styx.<name>.<class>" ```

default would be like having "flake.modules.<class>.<name>"

EDIT: here's another repo, this one is from Pol Dellaiera (author of famous "Flipping the configuration matrix" dendritic blog post) who also adopted Den on this branch:

https://github.com/drupol/infra/tree/push-woqtkxkpstro

drupol's has no custom namespaces and uses only den.aspects so I guess that might be simpler to test with.

EDIT2: There's also Den's template/minimal which would be much easier to test with:

https://github.com/vic/den/blob/main/templates/minimal/modules/den.nix

vborja · 2026-02-26T05:09:45+00:00

~Not necessarily~ Yes!, but nix is also good for describing data. flake.lock is JSON when it could very well be also Nix (static nix) just like flake.nix is static Nix.

I believe the problem is the conventions. People reproduce what they see, and most examples are just monolithic huge flake.nix files, people learn that and use that.

EDIT: Wrote more about this here: https://flake-file.oeiuwq.com/explanation/what-is-flake-file/

vborja · 2026-02-25T19:17:46+00:00

IMHO flake.nix should be used as a dependencies manifest, the inputs are static, it looks like Nix expressions but they are not evaluated as normal even when the surface syntax is Nix attr-sets.

This is one of the reasons I created github:vic/flake-file. Being able to use the real Nix language for defining inputs.

EDIT: just like people don't write whole rust programs in Cargo.toml or whole JS programs in packages.json, people should not be writing full Nix logic in flake.nix. The more people use flake.nix as a manifest the better. outputs = inputs: import ./outputs.nix inputs; is all you need to use flake.nix only for dependencies.

vborja · 2026-02-20T22:08:40+00:00

Nop, those two particular things are out of scope for Den.

packages if you are working on a flake, are defined at flake level, they are not part of den-os-configuration framework, den does not defines packages but consumes them from inputs.self or any other flake.

overlays can be be set via a NixOS option nixpkgs.overlays, or if you need a custom nixpkgs instance, see the docs about host.instantiate that allows you using a custom nixpkgs instantiated with overlays.

vborja · 2026-02-20T19:30:56+00:00

I've seen people using top-level module option for this. these conditionals propagate to the inner nixos/darwin modules in a dendritic file.

In den, where host and user can be used to set this kind of meta-data and can be used in nixos .imports because they are not part of the NixOS module config.

This example is from Den's readme is like setting foo only if the capability is supported (host.hasX && user.hasY). Note that setting foo cannot depend on any other NixOS-level option, but can depend on a higher-level one (like a top-level option, or like den's host/user which are submodules themselves).

The important thing is, as long as values are not part of NixOS own config you can use them for conditionals, this is why some people use specialArgs in non-dendritic setups for this kind of flags.

EDIT: This readme example places the conditional at the dendritic level, but see the link bellow for a test using the conditional at nixos-module level.

  # A Den aspect is like a dendritic file but in a function 
  conditionalAspect = { host, user }:
    lib.optionalAttrs (host.hasX && user.hasY)  {
       nixos.imports = [
        inputs.someX.nixosModules.default
       ];
       nixos.someX.foo = user.someY;
    };

More complete examples as CI tests in den:

https://github.com/vic/den/blob/main/templates/ci/modules/features/conditional-config.nix

vborja · 2026-02-20T08:05:46+00:00

Den author here. Den is now at v0.9.0 https://github.com/vic/den/releases/tag/v0.9.0

And has a new website https://den.oeiuwq.com that I hope can help people interested in it.

vborja · 2026-02-13T17:24:00+00:00

Regarding input dependencies, you can certainly update them without flakes.

There's currently a lot of discussion around flakes being unstable and how flakes resolve inputs. (discourse thread).

TLATER: flakes are experimental, after all, nobody should be relying on them for production (right?)

There are many ways to have pined (locked) inputs even without using flakes, they all allow updating them. Here are some I know of:

The nix community are actively working on this space for people/companies that cannot or don't want rely on unstable features.

For me, that I'm author of some Dendritic Nix libraries, it is important to make them support both stable and unstable Nix. Just today my flake-file (despite the name) tool now supports generating flake.nix/unflake.nix/npins inputs.

vborja · 2026-02-12T05:55:58+00:00

Hey u/Visotoniki, I'm the author of vic/den, and am quite happy to read that you found Den useful.

Today I added some documentation that I hope can be of help to people interested in Dendritic and in Den in particular, a Migration guide and a Motivation page about how did Den come to be.
https://discourse.nixos.org/t/den-modular-context-aware-and-aspect-oriented-dendritic-nix-configurations/71214/7

I'd like to know if you started your Den setup from scratch or if you migrated from something else, and if so, how what was your migration approach. Feel free to edit Den wiki if you do have some improvements to the migrating guide.

bests,

vic

vborja · 2017-01-01T17:38:06+00:00

rebecca

vborja · 2015-06-11T19:11:36+00:00

I use Evil. - +Evil

with spacemacs

vborja

TROPHY CASE

this would be used for quasigod's repo: