From 0a0a29fd0bb8329b33a0b2bb25627d3b3d9b7368 Mon Sep 17 00:00:00 2001 From: Shea Levy Date: Mon, 5 May 2014 16:30:51 -0400 Subject: [PATCH] Add comments about the module system interface Ideally the module system could be configured pretty much completely by the contents of the modules themselves, so add comments about avoiding complicating it further and possibly removing now-redundant configurability from the existing interface. --- lib/modules.nix | 16 ++++++++++++++-- lib/types.nix | 7 ++++++- nixos/lib/eval-config.nix | 22 +++++++++++++++++----- 3 files changed, 37 insertions(+), 8 deletions(-) diff --git a/lib/modules.nix b/lib/modules.nix index 1d7c7b22765..26193b26941 100644 --- a/lib/modules.nix +++ b/lib/modules.nix @@ -9,8 +9,19 @@ rec { /* Evaluate a set of modules. The result is a set of two attributes: ‘options’: the nested set of all option declarations, - and ‘config’: the nested set of all option values. */ - evalModules = { modules, prefix ? [], args ? {}, check ? true }: + and ‘config’: the nested set of all option values. + !!! Please think twice before adding to this argument list! The more + that is specified here instead of in the modules themselves the harder + it is to transparently move a set of modules to be a submodule of another + config (as the proper arguments need to be replicated at each call to + evalModules) and the less declarative the module set is. */ + evalModules = { modules + , prefix ? [] + , # !!! This can be specified modularly now, can we remove it? + args ? {} + , # !!! This can be specified modularly now, can we remove it? + check ? true + }: let internalModule = rec { _file = ./modules.nix; @@ -21,6 +32,7 @@ rec { __internal.args = mkOption { description = "Arguments passed to each module."; + # !!! Should this be types.uniq types.unspecified? type = types.attrsOf types.unspecified; internal = true; diff --git a/lib/types.nix b/lib/types.nix index 4d336c1d946..32f332ed21b 100644 --- a/lib/types.nix +++ b/lib/types.nix @@ -200,7 +200,12 @@ in rec { let coerce = def: if isFunction def then def else { config = def; }; modules = opts' ++ map (def: { _file = def.file; imports = [(coerce def.value)]; }) defs; - in (evalModules { inherit modules; args.name = last loc; prefix = loc; }).config; + in (evalModules { + inherit modules; + # !!! See comment about args in lib/modules.nix + args.name = last loc; + prefix = loc; + }).config; getSubOptions = prefix: (evalModules { modules = opts'; inherit prefix; # FIXME: hack to get shit to evaluate. diff --git a/nixos/lib/eval-config.nix b/nixos/lib/eval-config.nix index 4ee1c61f54f..b4b251d2581 100644 --- a/nixos/lib/eval-config.nix +++ b/nixos/lib/eval-config.nix @@ -2,12 +2,24 @@ # configuration object (`config') from which we can retrieve option # values. -{ system ? builtins.currentSystem -, pkgs ? null -, baseModules ? import ../modules/module-list.nix -, extraArgs ? {} +# !!! Please think twice before adding to this argument list! +# Ideally eval-config.nix would be an extremely thin wrapper +# around lib.evalModules, so that modular systems that have nixos configs +# as subcomponents (e.g. the container feature, or nixops if network +# expressions are ever made modular at the top level) can just use +# types.submodule instead of using eval-config.nix +{ # !!! system can be set modularly, would be nice to remove + system ? builtins.currentSystem +, # !!! is this argument needed any more? The pkgs argument can + # be set modularly anyway. + pkgs ? null +, # !!! what do we gain by making this configurable? + baseModules ? import ../modules/module-list.nix +, # !!! See comment about args in lib/modules.nix + extraArgs ? {} , modules -, check ? true +, # !!! See comment about check in lib/modules.nix + check ? true , prefix ? [] , lib ? import ../../lib }: