[Nix-dev] variable scope / recursion
Mathijs Kwik
mathijs at bluescreen303.nl
Fri Jul 6 14:42:39 CEST 2012
On Fri, Jul 6, 2012 at 2:39 PM, Kirill Elagin <kirelagin at gmail.com> wrote:
> But the ``__overrides`` will be empty in ``pkgsOrig``!
> Those new attributes are not... hmm... actually merged into the attrset,
> they still reside in this attribute and "pkgsOrig = pkgsFun pkgs {}"
> overwrites everything in __overrides with an empty attrset effectively
> removing all your overrides completely.
I see now.
Thanks for clearing that up :)
Now I can probably find a solution some other way.
Just needed to get clear what exactly was causing this.
Thanks
>
> --
> Кирилл Елагин
>
>
>
> 2012/7/6 Mathijs Kwik <mathijs at bluescreen303.nl>
>>
>> On Fri, Jul 6, 2012 at 2:28 PM, Kirill Elagin <kirelagin at gmail.com> wrote:
>> > 2012/7/6 Mathijs Kwik <mathijs at bluescreen303.nl>
>> >>
>> >> Yeah I saw those comments too, but I can't see how that would work.
>> >> Because the "original" (pkgsOrig) set is built by passing pkgs (the
>> >> final set) to pkgsFun.
>> >> In other words, the set references itself, which is perfectly normal
>> >> in a lazy setting.
>> >> The notion of "original" makes sense for the attributes that get
>> >> overwritten, but for the rest, I would expect a "shine through".
>> >
>> >
>> > As Shea already pointed out there is ``__overrides`` dark magic
>> > involved.
>> > Basically, your overrides are never added to pkgs directly, I mean,
>> > there is
>> > no something like "pkgs = overrides // origPkgs".
>>
>> The documentation clearly states __overrides is more powerful than //,
>> because // would leave the original set looking at the old values when
>> introspecting itself. With __overrides, they _do_ get added to the
>> set, and even replace the items inside, so other items in the set see
>> the new values.
>>
>> So this __overrides magic is indeed why I would expect this to work,
>> as it gives a consistent attrset which can look at itself and see the
>> (new) consistent view.
>>
>> >
>> > --
>> > Кирилл Елагин
>> >
>
>
More information about the nix-dev
mailing list