On Tue, Mar 29, 2011 at 11:42, Marc Weber <[email protected]> wrote: > Excerpts from ludo's message of Mon Mar 28 17:33:34 +0200 2011: >> Why is that? How should we work around it? > > In order to reproduce your problem having a configuration.nix file would > be benefical. I get the assertion only when setting kernelPackages and > enabling ttyBackgrounds. > > I'd vote for moving the code checking the assertions (assertions.nix) > > # This option is evaluated always. Thus the assertions are checked as well. > hacky! > environment.systemPackages = > if [] == failed then [] > else throw "\nFailed assertions:\n${concatStringsSep "\n" (map (x: "- > ${x}") failed)}"; > > > to eval-config.nix to ensure its evaluated first eg by adding this untested > code which surrounds the old config = by a let .. in catching the case that > assertion messages are present: > > # Optionally check wether all config values have corresponding > # option declarations. > config = > let cfg = > let doCheck = optionDefinitions.environment.checkConfigurationOptions; > in > assert doCheck -> pkgs.lib.checkModule "" systemModule; > systemModule.config; > failed = map (x: x.message) (filter (x: !x.assertion) cfg.assertions); > in if failed == [] then cfg > else throw "\nFailed assertions:\n${concatStringsSep "\n" (map (x: "- > ${x}") failed)}"
The problem I see here is that you cannot focus on small subset of your configuration if one assertion is failing unless you disable each module. The problem is raised when you may want to check for option values while trying to understand why you've got an error message (including the assertions). I would prefer to use properties for assertions (mkAssert), so an assertion made on an unused option has no effect. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
