Adopting den at vic/vix.

[vic]

So, I'm starting to actually use den in my own infra, I will be pushing to my den branch. But I'm posting about it because I believe it might be helpful for others, to see how I'm doing things in my own infra. Of course this is just my way of organizing things, and I'm sure you can come up with much better ways, feel free to also share what you come up with.

vic/vix#286 -- See the README at my den branch.

If you are brave enough to try my VM locally, just remove my modules/local_inputs.nix and nix run .#write-flake, and then nix run .#vm.

I'm liking a lot using a VM instead of having to re-boot everytime just to see if things worked. I recommend using this workflow, edit and run the vm loop.

So, I hope this can be useful for other people that have shown interest in using den for now.
So I will be shamelessly mentioning some of you (feel free to unsubscribe to this issue).
cc @HeitorAugustoLN, @Codys-Wright, @sebb3.

kudos and lots of love to @BlueberryBuns & @vorburger for recently becoming sponsors, thank you so much! if you find any of my work worth it, please consider sponsoring opensource, even if it is not me, opensource means lots of work/hours spent on creating stuff for others, and in my case non of those resources are paid for. So thank you so much to people willing to support whatever projects you love.

[vic]

Things I think would be great to have in vic/denful:

• Automatic CI pipelines generation (using mightyiam/files to generate the workflows). Similar to my current actions in my vix repo that I was using to build my 11 hosts.

• Generate an mdbook (again using files to generate markdown documentation from aspects definitions). Given that aspects have a tree structure and names and descriptions, we can potentially create a graph to show dependencies, or a navigable tree.

• Maybe the VM workflow, like my (profiles.nix + nargun.nix), because I'm liking a lot using the VM to develop.

• Having an impermanence module would be great.

• I will move my unfree.nix to den itself, as it is very tiny.

I want to keep den very tiny, I feel it is pretty much complete right now, and useful common modules should go into the denful repo.

One way to help me deciding what can be re-used is to browse my repo or try implementing den in your infra and see what common challenges we have and how we can find a good shared solution.

So, feel free to explore the code. All ideas are welcome, feel free to comment.

[HeitorAugustoLN]

I think it looks great, I am confused about non-dendritic (which for me it is cool to have), but I thought it was supposed to be non-flake dendritic setup (which you talked about on #14, which for me is kinda confusing, since I don't know how could this be achieved)

[vic]

My repo has been flakes since the beginning. But I'm interested in non-flake setups, it will probably be with other repo for now I wanted to dog-food my libs asap, and that for my infra means using flakes. Hopefully in coming weeks I will explore and publish more about non-flakes.

The idea of having non-dendritic is because I want to provide a path for people to migrate easily and also to have loading of auto-generated modules, like for hardware-related things that have no notion of dendritic nix.

[vic]

what is the thing that confuses you ? how to achieve non-flake dendritic setups ?. Dendritic was discovered on flake-parts setups, but IMHO that was just because flake-parts allows you to define cross-class definitions. Anything (any standard-nix or compatibility layer) that allows you the same is good for a dendritic setup, all you need is your nixosConfigurations/homeConfigurations to use the correct class module.

# this is current dendritic syntax:
{ vix, ... }: {
  vix.coding = { aspect, ... }:  {
    nixos = ...;
    darwin = ...;
    homeManager = ...;
  };
}

none of it is flakes specific (this code snippet works without flakes, see flake-aspects tests), it is just the nix module system at work. if you introduce self, inputs, perSystem that is flake-parts, but we might have ways to not use those or have a flake-parts compatibility layer (froyo is an experiment in that direction), or simply have other ways to access inputs/perSystem that are an abstraction over both flake-parts/stable-nix.

We will see in coming weeks.

[vic]

most my libs are flake-free (with flake-free I mean they do not depend on flakes, they do provide a flake.nix but that is because most of use are using flakes now, and even all nix logic is outside flake.nix)

except for two of them: den which is not all that tied except that it uses flake.nixosConfigurations as target for generated configs, but we could add den.<...> options later. and flake-file, which currently has a .#write-flake app, but nothing stop us from having another command that can use npins for producing sources.

[HeitorAugustoLN]

Yeah, setting it up which was confusing to me, but I get it now. I don't really plan to use it, since I really like flakes and can't live without it, but I’d like to know how it works just in case I change my mind.

[vic]

Yep, I also love flakes, but I understand why some people are trying to away from them. I also love exploring what is possible. So, unless I clearly see there's a dead-end, I will try to achieve it. As of today, I believe it is quite possible to have non-flakes dendritic setups.

[Codys-Wright]

Love the shameless mention! Feel free to at any time, heavily interested in the topic. I will certainly try this out when I can.
I'm slowly migrating some stuff over while I understand the general structure, then I'll break more things into modules etc, however, here is my config, no need to look at it but just contributing!

Nix-Config

I think I like the idea of keeping Hosts and Users outside of the modules, that way you know that the modules folder is entirely reusable and not fully linked to your actual system config.

Is Den aspects meant to fully replace Flake Aspects? like instead of defining everything with flake.aspects we would say den.aspects?

[vic]

Hey, I will certainly look at your repo, I love seeing what other people do. I'd also like to have an awesome-like list (probably as part of dendrix) of dendritic repos specifically, with short summary of what makes each repo unique. so people can look for inspiration on how others implement dendritic. Thanks for your contribution!

Regarding flake.aspects and den.aspects, I understand the concern, it was previously asked by @HeitorAugustoLN, and will try to respond here again:

The flake-aspects project (at the time of its inception) was just about transposition, its core is a simple transpose lib that just swapped attributes at second level, turning flake.aspects.<aspect>.<class> into flake.modules.<class>.<aspect>. That was the original feature. Then as den came to life, I started realizing I needed some support for tree-like structure of aspects (provides) and dependency graph (includes), both were integrated into the flake-aspects project since module resolution (aggregating all dependent modules) is part of the transposition. den initially generated new aspects in flake.aspects attribute, but I found that in doing so, any aspect that is added to flake.aspects is automatically transposed (and exposed) as part of flake.modules. For den, this means that if you have lots of hosts, and users, each of them will polute the flake.modules namespace. Your flake will expose lots of things particular to your (maybe-private) host/user names. So I decided for den to have its own private aspects namespace (it is actually just created with the flake-aspects project), and thus you have den.aspects and den.modules the only difference is they are not automatically exposed as part of the flake output, but you still have the option of exposing any part of them into flake.aspects.foo = den.aspects.foo or even just resolved modules: flake.modules.nixos.foo = den.modules.nixos.foo, you have freedom to choose what is exposed outside your flake. That's the reason behind den.aspects, it is just an aspect namespace implemented itself solely by the flake-aspects library.

Created a Q/A for this, as it is probable that other people have the same question and we can follow the topic there.

[vic]

Also, not generating aspects into flake.aspects (the attribute) is a step into non-flake usability.

My goal in coming weeks will be that den can also be used as a library (eg, you can choose it not to expose directly into flake.nixosConfigurations)

The default will be to just expose into flake.nixosConfigurations/homeConfigurations just like the flake-aspects project by default exposes into flake.modules.

[Codys-Wright]

Also, does converting everything to flake aspects mean we have a possibility of having a type-safe LSP server with aspects? We would need this for Dendrite anyway right?

Have in-editor completions for all modules would be super awesome :)

[HeitorAugustoLN]

you can probably try to add it in nixd: https://github.com/nix-community/nixd/blob/main/nixd/docs/configuration.md#options-options

[vic]

Aspects from a tree structure and a graph of dependencies, so in theory yes, you could have an LSP that provides auto-completion, but perhaps a nix-generic LSP can do that completions for you, no special need for custom lsp, right ? I dont use a nix LSP so I can't tell.

[Codys-Wright]

didn't know about nixd, will check it out!

[minhtrancccp]

@Codys-Wright have you figured out since how to make nixd works with den?

[sini]

@minhtrancccp This will be landing with the den-hoag rewrite in a couple weeks. That said I've had better success with nil.