[Nix-dev] Re: [Nix-commits] SVN commit: nix - r29021 - nixos/trunk/modules/misc

[Nicolas Pierron]

Hi,

On Mon, Sep 5, 2011 at 11:43, Eelco Dolstra <e.dolstra at tudelft.nl> wrote:
> On 09/05/2011 11:19 AM, Nicolas Pierron wrote:
>
>> +  optCall = f: x:
>> +    if builtins.isFunction f
>> +    then f x
>> +    else f;
>
> Attributes that can be both functions or not are a bad habit that we
> shouldn't propagate further :-)  It also makes behaviour of nixpkgs.config
> inconsistent with the semantics of the ~/.nixpkgs/config.nix.  Is there a
> good reason for this?

If the only case was to handle NixOS, then I wouldn't have accepted
functions here.  I have 3 reasons to use non-function and to give a
separate syntax from ~/.nixpkgs/config.nix.  The pkgs argument feels
duplicated and non-consistent with the rest of modules arguments.
Functions are hard to understand for non developers.  Functions are
not printable inside a documentation, thus they cannot be manipulated
easily by a tool.  Functions are causing merge problems (which was the
case here).

What I can suggest is a paradigm shift for ~/.nixpkgs/config.nix which
would use a module like syntax, where the whole file is a function,
and not only an attribute of the file.  Then we should avoid
getConfig, and only use override to define values of the options.
Then converge to a gentoo like freedom of choice.

-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/