[Nix-dev] joining attribute sets recursively

Nicolas Pierron nicolas.b.pierron at gmail.com
Mon Jan 16 22:05:26 CET 2012


On Mon, Jan 16, 2012 at 18:28, Florian Friesdorf <flo at chaoflow.net> wrote:
> On Mon, 16 Jan 2012 16:50:10 +0100, Eelco Dolstra <e.dolstra at tudelft.nl> wrote:
>> On 16/01/12 15:37, Florian Friesdorf wrote:
>>
>> > config = mkIf cfg.enable {
>> >   ...
>> >   powerManagement.cpuFreqGovernor = "ondemand";
>> > } // cfg.aggressive ? {
>> >   ...
>> >   powerManagement.scsiLinkPolicy = "min_power";
>> > } : {};
>>
>> Indeed it would be good to have a way of writing this down in a nice way.
>> (Using two different modules as Marc suggested isn't very elegant.)  Maybe
>> something like
>>
>>   config = mkUnion
>>     [ (mkIf cfg.foo {
>>         ... attrs ...
>>       })
>>       (mkIf cfg.bar {
>>         ... attrs ...
>>       })
>>       ...
>>     ];
>
> hmm - not sure whether mkUnion or mkMerge (as Marc suggests) cuts
> it. The term *merge* is pretty generic and it would depend on a merge
> algorithm what happens. A union for sets is defined as all elements
> without duplicates, with a quick search I could not find a definition
> for key/val pairs / associative arrays / attribute sets. Maybe looking
> at the possible behaviours helps finding a name:
>
> mkX [ {
>  a = 1;
>  b = 1;
>  c.a = 1;
> } {
>  b = 2;
>  c.b = 2;
>  d = 2;
> } ]
>
> possible results:
> - error because of colliding b
> - first value taken: { a = 1; b = 1; c = { a = 1; b = 2 }; d = 2}
> - last value taken:  { a = 1; b = 2; c = { a = 1; b = 2 }; d = 2}
> - both values taken: { a = 1; b = [1 2]; c = { a = 1; b = 2 }; d = 2}

 - both values taken: { a = 1; b = mkX [1 2]; c = mkX [ { a = 1; } { b
= 2; } ]; d = 2}

Currently the cleanest way to do so is to duplicate the condition on
the attributes, such as:

config = {
  boot = mkIf cfg.enable { … };
  services = mkIf cfg.aggressive { … };
};

By the way, usually the enable condition is wrapping everything and
what you want to do makes me wonder if the aggressive option does not
deserve another name.

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


More information about the nix-dev mailing list