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

Shea Levy shea at shealevy.com
Sat Feb 22 19:54:59 CET 2014



> On Feb 22, 2014, at 12:27, Nicolas Pierron <nicolas.b.pierron at gmail.com> wrote:
> 
> Hi all,
> 
>> On Wed, Feb 19, 2014 at 4:44 PM, Shea Levy <shea at shealevy.com> wrote:
>> Hi all,
>> 
>> The Problem
>> -----------
>> 
>> I've been doing a bit of work to make it possible to define nixops
>> networks modularly in the same way we do NixOS configs (with each
>> machine in a network being a submodule),
> 
> I think this is a good idea, that's what I tried to motivate during
> the making of disnix, but apparently failed to explain / explicit to
> get it adopted.
> 
>> and in doing so I've repeatedly
>> run into issues due to the fact that NixOS's modules take a bunch of
>> arguments beyond config, options, and lib, in particluar that they take
>> 'pkgs'. The problem with these extra arguments in general is that they
>> are superfluous and non-modular: superfluous, because any internal
>> values we want to make accessible to all modules can be put into config;
> 
> Yes for packages, even if they are extremely convenient to have as a
> first argument, but no for the module logic. (mkIf, mkOption, ...)
> 

Right, that's why in addition to config and options I consider lib (particularly, the lib whose evalModules was called) an integral part of the module system interface. pkgs etc. are less so.

> Also, having pkgs as an argument is a convenient shortcut for all
> expressions.  One way to transition would be to define pkgs as being
> extracted from the result.
> 
> let
>  moduleWithPkgs = result: m: args: m (args // { pkgs =
> result.config.nixpkgs.pkgs });
> in

Yeah, it seems like everyone likes this idea (similar to my config._args idea). After 14.02 I will fix all uses of pkgs.lib and open a PR to introduce this.

>  ...
> 
> I have always made changes such as we can give a LONG grace period for
> migrating.  People might remember the "require" attributes, the
> rename.nix file[1], or the "pkgs.types.loaOf".
> 
> The reason why I did so is the same reason why I switched to NixOS in
> the first place, *not having to* update, *but choosing when I want to*
> update.
> 
> This is exactly the same idea we have behind the "--rollback" option.
> Even if the rollback option is not evaluating Nix code, we still want
> users to experiment with their old configuration for a while, such as
> they are not forced to update at one time, but within a grace period.
> 

Yeah, if we do deprecate all other args all together (which Eelco doesn't seem to like, so probably not), there's no reason we can't do it gradually.

> In terms of solution, I have no problem adding a pkgs argument to all
> sub-modules arguments, even if it defaults to an error message when
> the "pkgs" option does not exist.  We can do that while we ensure that
> all mkFunctions are extracted from the "lib" attribute, and not
> "pkgs.lib".  Then, later we can remove this pkgs argument.
> 
> [1] https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/rename.nix
> 
> -- 
> Nicolas Pierron
> http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/


More information about the nix-dev mailing list