Hi, On Mon, Sep 5, 2011 at 11:43, Eelco Dolstra <e.dols...@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/ _______________________________________________ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
