Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

v0.13.0 #314

vic announced in Announcements
Mar 19, 2026 · 0 comments
Discussion options

Den v0.13.0

More Elven Shamanic Nix now with less Bifurcated Polynomial Applicatives, much better for health!.

What's Changed

New Contributors

Full Changelog: v0.12.0...v0.13.0


Den v0.13 Release Notes

This release focuses on context-pipeline behavior clarity, class forwarding, and API ergonomics. It also removes the old bidirectional behaviour that was causing duplicate-values in favor of explicit mutual routing.

Den v0.13 depends on flake-aspects v0.7.0, no changes to flake-aspects were needed.

Highlights

  1. Mutual host/user routing replaces bidirectional battery
  • den._.bidirectional was first extracted from Den core into a battery and then removed.
  • den._.mutual-provider is the supported mechanism for Host providing home-environments to all users.
  • New explicit routing conventions:
    • host -> users: den.aspects.<host>.provides.to-users.*
    • user -> hosts: den.aspects.<user>.provides.to-hosts.*
    • specific peer routing still supported via den.aspects.<user>.provides.<host> or den.aspects.<host>.provides.<user>
  1. Forwarding classes now support top-level alias forwarding
  • den._.forward now supports intoPath = [ ] for root forwarding.
  • Guarded root forwarding and adapted args are supported for alias-style classes.
  • Added Examples for for guarded forwards with config-sensitive conditions like platform-specific hm classes.
  1. Parametric behavior fix for nested plain-attrs includes
  • Nested includes are treated correctly as parametric when function args are declared.
  1. New context helpers in den.lib
  • den.lib.perHost
  • den.lib.perUser
  • den.lib.perHome
  • These provide explicit context-scoped include intent and reduce usage of den.lib.take.exactly({host,user}) patterns in code.
  • They work with plain attrs or ctx-taking functions.
  1. Better den.lib and framework module organization
  • Core lib split into nix/lib/* modules.
  • default.nix and flake.nix are basically the same.

Migration Notes

1) Replace bidirectional patterns

Migration path

Until v0.12.0 Den had built-in Bidirectionality in its core.

What that meant was that Host aspects could contribute
home classes like homeManager to all its users. However
this was also the source of many duplicate reports, becuse
the Host aspect was being activated more than once: when the host was reading its own config and then later for each user context {host,user}.

We also had a "routing example" that @musjj then moved to what is now den.provides.mutual-provider #236, that contribution made us wonder if the built-in bidirectionality could be extracted from core #273 (we did) and then further conversations led to actually removing it #300 after realizing it was more complicated than necessary.

2) Forward alias classes can target class root

Previsouly or forward battery was not able to use intoPath = [] (forward into top-level target module).

Now it is possible, enabling other patterns like classes
that guard on reading from config values or things like pkgs platform:

tests

den._.forward {
 each = [ "Linux" "Darwin" ];
 fromClass = p: "hm${p}";
 intoClass = _: "homeManager";
 intoPath = _: [ ];
 fromAspect = _: lib.head aspect-chain;
 guard = { pkgs, ... }: p: lib.mkIf pkgs.stdenv."is${p}";
 adaptArgs = { config, ... }: { osConfig = config; };
}

3) Use explicit helpers for context intent

Prefer:

perHost ({ host }: { ... })
perUser ({ host, user }: { ... })
perHome ({ home }: { ... })

Over generic den.lib.take.exactly forms when intent is narrow. These forms document better the code intention. All these three work with plain attrs or functions.

4) Standalone homes bound to existing host/user gain automatic os args

Homes named like "user@host" now behaves consistently with hosted HM flows. For example, having:

den.homes.x86_64-linux."tux@igloo" = {};
den.hosts.x86_64-linux.igloo.users.tux = {};

Will

  • Correctly set <home>.userName so that batteries like define-user work.
  • Automatically bind the standalone HM instance to the OS host configuration.

This means that by declaring tux@igloo you can quickly rebuild your home
environment without rebuilding the whole igloo OS.

5) Extended schema modules for users and homes.

User schema modules an also access their host:

den.schema.user = { host, user, lib, ... }: {
 options.foo = lib.mkOption { };
};

Also standalone HM bound to an "user@host" pair give you access to home.user and home.host meaning the home object is bound to those.

User can access the host it was difined-in, via user.host, possibly rendering {host,user} into only {user} in the future -not sure-.

CI/Test and Tooling Changes

  • Added CI/workflow. update latest tag upon release, docs/test workflow changes, semantic PR updates.
  • Added shell.nix and exported devShells from flake output for contributors.

Docs and Naming Updates

  • New docs page for mutual routing: guides/mutual.
  • Custom classes and batteries docs updated to emphasize forward/mutual patterns.
  • Release/versioning docs linked from README.

Recommended Upgrade Checklist

  1. Remove any den._.bidirectional usage.
  2. Enable mutual routing explicitly with den.ctx.user.includes = [ den._.mutual-provider ]; where needed.
  3. Move host->user routing to <host>.provides.to-users and user->host routing to <user>.provides.to-hosts.
  4. Replace den.lib.take.atLeast/exactly includes with perHost/perUser/perHome where appropriate.

This discussion was created from the release v0.13.0.
You must be logged in to vote

Replies: 0 comments

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
1 participant

AltStyle によって変換されたページ (->オリジナル) /