Feature requests braindump

[vic]

Add new ideas, you can also leave a 👍 if you find any of them important to you.

You can also open another discussion in the Ideas category, this one is just a brain dump of things that may or may never be part of Den. If something feels like plausible, lets move to its own Ideas thread.

[vic]

A template using adios modules or adios-flake instead of flake-parts just for fun and to compare memoization and speed.

[sjdevries]

A fleet sounds interesting, and vaguely similar to a clan.

I would love if den / denful had an equivalent at some point. Mostly that would require having aspects for the following:

• Secret Management (Sops-Nix, Agenix + Agenix-Rekey + Agenix-Template, Vars, or SecretSpec)
• VPN (Netbird, Reticulum, or others listed here)
• Nixos-Anywhere - installation for cloud or remote machines
• Disko - automated drive formatting during installation
• Facter - hardware configuration
• an example command for building an installer iso for bare metal installation.

I am hoping secrets become a lot easier if a nixos module becomes available for SecretSpec, or Vars gets upstreamed.

I've already seen others here inquiring about Disko and Facter so hopefully these pieces can start to come together.

[vic]

Haven't used Clan, I'd like to have some time to read the docs, I'm not familiar with it, but have read people talking about it a lot.

I guess fleets are very doable in Den because we have ctx-traversals (basically traverse an entities definition, fleet -> machines -> services, hosts -> users -> homes, etc).

So having fleets is more about designing the structure and a context pipeline that traverses it.

Currently my own need is just to have peers knownHosts and user ssh-keys replicated on all fleet members, maybe that is a good start.

[vic]

flake-file integration that allows to extract inputs that are needed only for some aspect and its dependencies.

[vic]

I'd like to allow other outputs than nixosConfigurations, noticed this when doing our templates/nvf-standalone.

[vic]

Den has flake output support. https://den.oeiuwq.com/reference/output/#flake-outputs-like-packages-checks-etc for packages, shells, etc.

We might still need support for other custom outputs like flake.fleetInventories or things like that

[vic]

I'd like to have examples of extending the ctx pipeline (we have one microvm) but I believe ctx transitions written by people would unleash new patterns. So I need to document that.

[vic]

I've been thinking about a templates/fleet that uses a schema.fleet, ctx.host.into.fleet-member to define members of same network, and each host has access to its peers and can configure things like ssh knownHosts, etc.

[vic]

I've also been thinking of a checks custom class that forwards up to the flake level, so each aspect could export tests. Not sure about how yet.
also packages.

[vic]

completed: https://den.oeiuwq.com/reference/output/#flake-outputs-like-packages-checks-etc

[teamwolfyta]

Publish "stable" and "unstable" versions of documentation where "stable" would the latest GitHub release and "unstable" would be the master branch.

[vic]

@teamwolfyta see here: 841dbf3

[teamwolfyta]

Absolutely perfect, thanks @vic!

[theutz]

More of a docs thing, but I think it might be interesting to develop something like a "standard" project layout. Not for aspects, necessarily. But I think that it might be useful to have something like this as a starting point:

.
├── modules/
│   ├── aspects/
│   │   ├── cli/
│   │   │   └── ed.nix
│   │   ├── tui/
│   │   │   └── neovim.nix
│   │   └── gui/
│   │       └── neovide.nix
│   ├── contexts/
│   │   ├── user.nix
│   │   └── host.nix 
│   ├── targets/
│   │   ├── nixos/
│   │   │   └── igloo/
│   │   │       └── host.nix
│   │   ├── darwin
│   │   └── homeManager/
│   │       └── tux/
│   │           └── user.nix
│   └── batteries/
│       └── hmPlatforms.nix
├── flake.nix
└── flake.lock

Of course, it'd be important to emphasize that den doesn't enforce any kind of folder structure and they're free to change this however they want. But this kind of concrete guidance might help newcomers grasp the nature of what den is doing and help with the "blank page" problem when trying to get things setup.

Ruby on Rails, Laravel, and probably countless other frameworks have benefited from giving users a jumping off point like this. snowfall/lib was starting to do that before it was abandoned, and that really helped me learn Nix. But it was too constraining after awhile. I think den gives the flexibility that snowfall/lib could never provide.

Finally, having a standard layout like this might make it easier for people to grok the example templates that you've setup. I've found that familiar landmarks like this cut down a lot of the mental energy when learning a new code base.

[vic]

Yep, maybe we could use our templates/example for that, the intention for it was to be a more complete working base than default and much more than minimal. If you are ok with contributing refactors to templates/example for that, I'd take that.

[vic]

Also take a look at structure https://github.com/Gwenodai/nixos/tree/main/modules, I personally like the naming convention inspired by https://github.com/Doc-Steve/dendritic-design-with-flake-parts. Maybe we start a dedicated thread for this and we can come up with some nice starting point for people. I'd love @Gwenodai input on this.

[theutz]

I'd be happy to! Maybe I'll leave this comment here for a few days before I get started just in case anyone has any better ideas about the structure than I do so I can learn from their wisdoms. :D

[vic]

Thread for this: #363

[NireBryce]

just chiming in that this is an excellent idea, because the example real-world configurations given on the repo page aren't very good at showing off the concepts if you don't already know everything in the ecosystem and were a big part of me getting lost the first time.

[theutz]

More syntax sugar for includes, like:

<cli/*>        # includes all sub-aspects for this aspect (alias for attrValues trick?)
<cli/btop,bat> # expands to include `cli._.btop` and `cli._.bat`

[theutz]

I was actually reading your config, @Gwenodai, when the idea came to me! :D

[Gwenodai]

I was actually reading your config, @Gwenodai, when the idea came to me! :D

Haha I had a feeling that might have been where the specific examples came from.

[NireBryce]

I'd almost say even though it looks ugly, maybe going closer to nix idiomatic might work

<cli/[ btop bat ]>
/

<cli/[
    btop 
    bat
]> 

[vic]

Interesting idea, maybe I lean towards a basic glob-like syntax, <foo/{b*,cat}> the result of that would be an aspect with includes of all those that match names. Currently our __findFile impl is just sugar for attrByPath (/ -> .provides., split on . and use attrByPath). If anyone is willing to take a try on this, PRs are more than welcome.

[theutz]

This feels like a task I could possible take a first swing at.

[theutz]

I don't know if this would really make sense, but when defining a custom class, would could den auto-generate an aspect for the class? Kind of like you do for host, user, and home?

[vic]

This one, sadly does not make much sense to me.

Hm, can't find the relation between a custom class and generated aspects. We generate aspects for host/user/homes because they are configurable entities.

We can generate those aspects because we know beforehand where to look for things den.hosts.*.<host>.users.<user>, I'm not sure that is the case for custom classes, there's no central registry nor there will be, they can also be anonymous or let-bindings on some files. So "auto-generating" aspects for them might need to have some place to look for things to generate. I don't thing we need that.

Say you define a custom class git, the class makes sense inside aspects, and you can already define your own den.aspects.git = { git = ... } if you wanted like all git configuration branch from there. But that is an aspect organization preference.

[theutz]

Ah, I see what you're saying. I was thinking of this from the perspective of the flake-parts modules, and for a bit it made sense. But, yeah, now that I think about it, there's WAY more edge cases than there are standard practices there. So, probably not a winning idea. :)

[landon-buttars-wgu]

Feature Request: Sibling Provider Presence Detection

Summary

It would be useful to conditionally check whether a sibling provider is active within a host configuration, so that providers can avoid conflicts when both contribute to the same config.

Motivation

When multiple providers contribute to the same configuration surface, they can conflict. The natural place to resolve this is within the provider's own configuration block, but providers currently have no way to query whether a sibling provider is active on the same host.

Example

A tmux provider sets a default status bar, and a gitmux provider also defines a status bar configuration. When both are active on a host, they conflict. The tmux provider should be able to detect that gitmux is active and skip its default status bar line accordingly.

The only current workaround is a parametric include, which requires duplicating recursive resolution logic inline and scatters configuration that logically belongs together:

aegis.tmux = {
  homeManager = { pkgs, ... }: {
    programs.tmux.extraConfig = ''
      # status-right must be split out into a parametric
      # because provider context is not available here
    '';
  };

  includes = [
    ({ host, lib, ... }:
      let
        hasAspect =
          name: node:
          (node.name or null) == name
          || lib.any (hasAspect name) (node.includes or [ ]);
        hasGitmux = hasAspect "gitmux" host.resolved;
      in
      lib.optionalAttrs (!hasGitmux) {
        homeManager.programs.tmux.extraConfig = ''
          set -g status-right '#{?pane_in_mode,#[fg=yellow][COPY],}#{?window_zoomed_flag,#[fg=red][ZOOM],}'
        '';
      }
    )
  ];
};

Requirements

• A provider must be able to detect whether a sibling provider is active on the same host from within its own configuration block
• The check must reflect the fully resolved provider tree, including transitive includes
• It must not introduce cycles into the module fixpoint

[sini]

@vic I think this is going to be a common enough pattern that it would make sense to directly expose it on context entities built on their resolved graph. I will implement it for aspects as well, though I feel it makes less sense there.

[landon-buttars-wgu]

@sini For my use case, host/user context scoping for a given class is sufficient.

I primarily intend to use this in Home Manager classes within my aspects to deconflict extraConfig between base configurations and providers.

Thanks for the quick follow up gents.

[sini]

This is in progress now at #439. The spec covers your use-case, as your provided example doesn't introduce graph resolution cycles. :)

[sini]

Feature is now on main, let me know if you need followup functionality.

[charlesfire]

Have a user-packages and a system-packages battery :

den.aspects.games = {
    includes = [
        (den.provides.user-packages [ "prismlauncher" "airshipper" ])
    ];
};
# Aspect games includes a sub aspect that includes prismlauncher and airshipper in user packages.

den.aspects.base = {
    includes = [
        (den.provides.system-packages [ "thunderbird" ])
    ];
};
# Aspect base includes a sub aspect that includes thunderbird in systemPackages.

[charlesfire]

This would be useful for aspects that provides several packages instead of just including them :

den.aspects.games = let
    prismlauncher = (den.provides.user-packages [ "prismlauncher" ]);
    airshipper = (den.provides.user-packages [ "airshipper" ]);
in {
    provides = {
        inherit prismlauncher;
        inherit airshipper;
    };
    
    includes = [
        prismlauncher
        airshipper
    ];
};

#Now games aspect can be included to include all defined game packages or we can include specific games with the angle bracket syntax <games/airshipper>

[charlesfire]

I made a draft implementation of this feature here. I hope to get feedback on the implementation, the proposed api and the general idea of this feature.