How can I pass specialArgs / extraSpecialArgs / extraSuperExpecialArgs ?

[vic]

Some people might want to have a migration path for configs already using specialArgs but using it is considered an anti-pattern in Dendritic setups.

[vic]

The need for specialArgs

Using specialArgs is considered an anti-pattern in Dendritic nix because it is normally used to communicate values between modules of different nix classes. For example, in non-dendritic you have two files host/a.nix (nixos class) and home/a.nix (homeManager class). Since they are separate files, in order to communicate something from one side to the other you need to use specialArgs. This passing of special value is normally done in yet another (flake class) file, normally flake.nix which can instantiate both os/home configurations passing shared values via specialArgs.

Communicating values in Dendritic

However in a Dendritic setup, each file is considered to be a flake class module (since they are are always commonly used with flake-parts and imported at flake level).

Each Dendritic file can have multiple nix configuration classes:

# there is nothing den specific here:
let
  sharedValue = ...;
in
{
  flake.modules.nixos.foo = {
    # use sharedValue in nixos class module.
  };

  flake.modules.homeManager.foo = {
    # use sharedValue in homeManager class module.
  };
}

as you can see, by simply using let-bindings it is possible to communicate values between different configuration classes without relying on using specialArgs. That's why the Dendritic recommendation is not to use them.

The very same is possible in den configurations since they are also Dendritic modules.

let
  specialValue = ...;
in
{
  den.aspects.foo = {
    nixos = ...; # use specialValue in nixos class module.
    homeManager = ...; use specialValue in homeManager class module.
  };
}

Passing values to other files not just in the same let-binding context. (original question)

When passing values between files the most likely working approach is to define your own configuration options at the flake class level. That is,

# modules/my-specials.nix
{ lib, ...}:
{
  config.my-specials.specialValue = ...; # a value accessible on all modules.
  options.my-specials.specialValue = lib.mkOption {
    type = lib.types.anything; # or set a property type.
  };
}

Then you can use that value from other files:

# here not using `den` but generic flake-parts Dendritic syntax:
{ config, ... }: 
{
  flake.modules.nixos.foo = ...; # access config.my-specials.specialValue
  flake.modules.homeManager.foo = ...; # access config.my-specials.specialValue 
}

The den approach.

In den you can do exactly the same as in pure flake-parts Dendritic modules. However since den defines its host/user/home types as freeform types, you can add any custom metadata to them. And then access them via host.<attribute> in any aspect to produce any class configuration based on it.

So, den already implements the pattern described above, you add specialValues to your host/user/home from whatever module you like and also access them from whatever aspect you need, independent of file location:

# modules/metadata.nix
{
  # note that my-laptop users need not to be defined here, maybe they are defined at hosts.nix.
  # this file only sets metadata.
  den.hosts.x86_64-linux.my-laptop = { 
    vpn-name = "work"; # custom attributes here   
  };
}

and then

# modules/vpn.nix -- the vpn aspect
{ den, ... }:
{
  # or in any parametric aspect
  den.aspects.vpn = { host }: {
    nixos = ...; # use host.vpn-name
    homeManager = ...; # use host.vpn-name
  };
}

I still want to use specialArgs/extraSpecialArgs.

If you really have no other way around, you can set the host or home's instantiate function that is used to build the configuration. This way you can build the configuration yourself with any input channel or with specialArgs.

For reference, see this CI commit showing home-manager extraSpecialArgs where a standalone home-manager configuration needs access to extraSpecialArgs.osConfig.