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

[Shea Levy]

On Wed, Feb 19, 2014 at 12:30:00PM -0500, Shea Levy wrote:
> 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.
>

Although taking a second look at it, while I do still think I need
submoduleWithExtraArgs I won't need dependentAttrsOf if I do something
similar to how that option is a submodule, one of whose options is
another submodule.

> 
> >
> > -- 
> > 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
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev