Skip to content

v0.11.0

Choose a tag to compare

@vic vic released this 06 Mar 01:18
· 339 commits to main since this release

Here's Den v0.11.0. This release is mostly about improvements to forwarding classes, multi home-environment support and bug fixes.

Improvements to forwarding classes and their documentation

Many people started using forwarding classes, and came up with great ideas that either became examples in our documentation or built-in batteries like our os class (which forwards to both nixos and darwin).

People using this uncovered some bugs we fixed in this release. As always I'm really thankful to people using Den and reporting issues, because that's the only way I can notice something went wrong.

den.default is a real aspect (again)

But now den.ctx.default = den.default. This is because using lib.mkAliasOption was producing wrong locations. The location is always reported as a file in Den source code and not the real location where people defined settings. The same problem happens with ._. alias for .provides. from flake-aspects, however we cannot remove that alias. Bug report here: https://discourse.nixos.org/t/lib-mkalias-renamedoptionmodule-doesnt-preserve-location-of-option-definition/75879

den.lib and /default.nix

Improved usability of Den as a library, our default.nix exposes den.lib and a nixModule that can be included in any module system (be it flake-parts, falake, lib.evalModules, etc).

Our Den library includes den.ctx and den.aspects but without any NixOS / Homes specifics, allowing people to use Den configuration model (context-driven + aspects) for other Nix domains (like cloud infra).

We have tests for this at den-as-library.nix CI test.

This den.lib feature also helped us with a very weird bug #216 by not having anything of the NixOS/Homes stuff normal Den framework does.

Made all batteries use take.exactly

Batteries are also examples, so it is important for them to be as correct as possible. Just in case people copy from them, we now make them use exactly matching on context.

Enabling home-manager or other home-envs.

Den has always been feature opt-in, the reason is not all people have the same needs and also because not having all features enabled at the same time helps with hunting bugs.

Previously, our home-manager integration was enabled via an aspect den.provides.home-manager. Which many people used to include in den.default.includes = [ den._.home-manager ]. We are now trying to move away from den.default as much as we can at least in core. den.default is useful and will not be removed, but since we introduced den.ctx we have better ways to include re-usable aspects.

We also have support for other home-environments, hjem and nix-maid, because of this, a single user can now choose to use any combination of home-manager and others, or none (simply using the user forwarded class). Because we now many home environments, none of them is preferred by Den. And, it is a user concern which of them each user chooses to have.

home-manager, hjem, and nix-maid work the same in Den, they use forwarding classes and are enabled when host.hjem.enable = true (or equivalent). By default this .enable value is: "has any of my users a hjem in its classes?", because the context types for each type of home den.ctx.hjem-host only activate when at least one user has requested hjem.

So now instead of using den.provides.home-manager, which home environments are active is a responsability of each user.

den.hosts.x86_64-linux.igloo.users.tux.classes = [ "homeManager" ];

However this can get repetitive when having multiple hosts or users, so you can use the den.ctx.user base schema to specify in YOUR configuration that homeManager is preferred.

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

The old den.provides.home-manager aspect does nothing, it raises an error telling you to now specify user.classes.

We now have proper WSL support

And a corresponding den.ctx.wsl-host pipeline when WSL is enabled.

intoAttr is now a path.

You can change where a configuration is placed, this is useful for standalone home-manager and some WSL nixos configs.

den.homes.x86_64-darwin.tuxie = {
   intoPath = [ "homeConfigurations"  "tux@igloo" ];
}

noflakes template updated with multi-host suppot and nh apps.

Den can produce an nh based app for activating each host, this is currently only part of the noflake template, but will later be added to other flakes and documented on how to use in existing flakes.

What's Changed

  • Fix nix-maid link in noflake tutorial by @drupol in #194
  • Only apply unfree to nixos/darwin/homeManager by @OscarMarshall in #196
  • CI: tests first and templates until approved by @vic in #199
  • fix: den.fwd.adapter.user already defined by @vic in #202
  • fix include-less parametric in provides by @musjj in #208
  • Make intoAttr a path by @vic in #211
  • add wsl class and den.ctx.wsl-host by @vic in #213
  • Home integration now enabled via host config for hm, nix-maid, hjem by @vic in #215
  • docs by @vic in #217
  • move context apply functions to own file by @vic in #218
  • make batteries use parametric.exactly by @vic in #220
  • fix wrong location issue of option definied in den.default by @phhai-hcmut in #221
  • feat: os class forwards to NixOS and MacOS by @vic in #225
  • feat: apps per host for build/swith/repl using nix-community/nh by @vic in #227
  • remove duplicate code between homes by @vic in #229
  • feat: default.nix exposes clean den API without NixOS domain by @vic in #230
  • update flake-aspects, test no merged aspect.__functor by @vic in #231

New Contributors

Full Changelog: v0.10.0...v0.11.0