Having either argument defined based on the OS is a problem when
trying to write generic Nix code.
The current workaround is to use accept both and specify a default
value for each argument:
```
{ config, lib, nixosConfig ? {}, darwinConfig ? {}, ... }:
let
osConfig = nixosConfig // darwinConfig;
in
{
# Do something with `osConfig`
}
```
With this commit, it becomes possible to do the following:
```
{ config, lib, osConfig, ... }:
{
# Do something with `osConfig`
}
```
functionTo tries to evaluate functions too quickly and prevents modules
from accessing pkgs argument. fixes#1878.
Co-authored-by: Pacman99 <pachum99@gmail.com>
This allows users of the nixos and nix-darwin module to set shared modules
for all users and extra specialArgs to be available to home-manager modules.
The latter is named extraSpecialArgs just like the argument to
modules/default.nix.
This could be confusing since the the two are independent in code,
but they do mean the same thing so I think the name fits.
Darwin can now refer to the global system configuration if used as a module
through the special `darwinConfig` argument.
Co-authored-by: Nicolas Berbiche <nicolas@normie.dev>
Before the profile directory value would point directly to the build
output in the Nix store. Unfortunately this would cause an infinite
loop if the user's configuration directly or indirectly refers to the
profile directory value.
Fixes#1188
It is insufficient to install the packages in `home.packages`, it has
to be `home.path`, which includes configured extra package outputs or
profile commands.
This change makes use of the `extend` function inside `lib` to inject
a new `hm` field containing the Home Manager library functions. This
simplifies use of the Home Manager library in the modules and reduces
the risk of accidental infinite recursion.
PR #994
This removes the `nixosSubmodule` option in favor of a new option
`submoduleSupport.enable`. This name better indicates that the
submodule mode applies to both NixOS and nix-darwin.
