[Nix-dev] Fixing module arguments (PROPOSAL MAY BREAK EXISTING NIXOS CONFIGS, PLEASE READ)

Eelco Dolstra eelco.dolstra at logicblox.com
Wed Feb 19 18:05:36 CET 2014


Hi,

On 19/02/14 16:44, Shea Levy wrote:

> Hi all,
<snip>

IMHO, removing the "pkgs" argument has basically no advantages to users, and a
lot of disadvantages (namely, it breaks pretty much every existing module, and
makes modules more verbose).

> * The configuration must be partially evaluated with a default value for
>   pkgs and then *re-evaluated* with the final value for pkgs. Due to how
>   this partial evaluation works (only configuration.nix, its imports,
>   and nixpkgs.nix are included in the evaluation), no modules in
>   module-list.nix except nixpkgs.nix can affect pkgs.

So the problem is not the "pkgs" argument, it's the circular dependency in
defining "pkgs" because modules do things like "pkgs.lib.mkOption".  If they
used "config.nixpkgs.pkgs.lib.mkOption", you would have exactly the same
problem.  If you get rid of references to "pkgs.lib" (at least in the "critical
path" used to define "pkgs") then the whole problem goes away.

So I'm all in favor of rewriting modules that do

  { config, pkgs, ... }:

  with pkgs.lib;

to

  { config, pkgs, lib, ... }:

  with lib;

> The additional practical effects this has on my implementation of
> modular nixops networks are:
> 
> * I need a new type "submoduleWithExtraArgs", as the submodule type
>   doesn't pass any extra arguments besides "name" to the submodules and
>   that can't work with using NixOS configurations as submodules.
> * I need a new type "dependentAttrsOf", where the type of the attr value
>   can depend on the attr name, as different machines in one network
>   might have different settings for nixpkgs.config and thus should be
>   passed different values of pkgs, but as per point 1 the arguments
>   passed to the submodule have to be part of the type
> * I have to duplicate NixOS's two-phase eval for *each* machine in the
>   network

I don't really see why you need any of these things.  For instance, the
implementation of NixOS containers supports having NixOS sub-configurations just
fine without them.

-- 
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/


More information about the nix-dev mailing list