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

[Shea Levy]

Hey Eelco,

On Wed, Feb 19, 2014 at 06:05:36PM +0100, Eelco Dolstra wrote:
> 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).
> 

IMO a cleaner interface and improved maintainablity are advantages to
users, but I take your point.

>
> > * 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;
> 

If you agree with requiring this change, then I get 95% of what I want.
Great :). Could even implement part of the conservative proposal so that
arguments can be handled modularly without changing the user interface
at all.

>
> > 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.
> 

I'd argue that the NixOS container support implements a version of these
types (though not the double-import duplication), but without the type
checking. The 'config' submodule argument has no type but really it's
meant to be a submodule, and instead of letting the submodule merge
function evaluate the list of values you pass them off to
eval-config.nix. That's replicating nearly all the work the submodule
type does, and if I were to do something similar for all of the current
resource types (which after all take a "resources" and "uuid" argument)
I'd need to replicate *all* of the work as I don't have an
eval-config.nix to fall back on for e.g. s3Buckets.

>
> -- 
> Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev