[Nix-dev] Anyone against giving the nixpkgs attrset a reference to itself?

[Nicolas Pierron]

On Thu, Jul 19, 2012 at 8:50 AM, Mathijs Kwik <mathijs at bluescreen303.nl> wrote:
> On Thu, Jul 19, 2012 at 5:40 PM, Nicolas Pierron
> <nicolas.b.pierron at gmail.com> wrote:
>> On Thu, Jul 19, 2012 at 6:03 AM, Mathijs Kwik <mathijs at bluescreen303.nl> wrote:
>>> On Wed, Jul 18, 2012 at 7:12 AM, Nicolas Pierron <nicolas.b.pierron at gmail.com> wrote:
>>>> On Mon, Jul 16, 2012 at 12:32 AM, Mathijs Kwik <mathijs at bluescreen303.nl> wrote:
>>>>> I would like to add the final nixpkgs attrset (defaults + overrides)
>>>>> to itself (named finalPkgs).
>>>>> As this is a somewhat strange thing to do, I thought it would be best
>>>>> to ask first :)
>>>>
>>>> strange ?  No, this is the base principle of NixOS.  In fact I would
>>>> almost recommend you to use a similar idea because I think we should
>>>> get rid of __override.
>>>>
>>>> […]
>>>>
>>>> Then we can extend this list with various index files either search at
>>>> default locations, given as arguments or listed in an environment
>>>> variable.
>>>
>>> That sounds very extensible indeed.
>>> Can this also be used to override certain attributes of other package
>>> sets (like kde or emacs in your example) in such a way that other
>>> (rec) attributes of the originating package set "see" it (like
>>> __override gives us)?
>>>
>>> Because I don't just want to add completely separate package sets, but
>>> modify the behaviour of the "official" set as well.
>>
>> Indeed, the latest example does not allow to override, but we can
>> imagine to merge by using some-kind of priority flag within the
>> derivation if there is a collision, and then only throw if 2
>> derivations have the same rank.
>
> That's not enough.
> That only creates a result attrset with an attr overridden.
> But if the original attrset used 'rec', neighboring attrs would still
> use the old definition.
> Or can they already reference the final resultset (have callPackage use it)?

As you mentionned the rec skips the result attrset, but callPackage
should fill the arguments with the resulting attribute set and not
with the one of the current set of packages, which makes no sense.

One use of rec can be to redefine a package locally with a lower
priority and make it use by a few other packages with a higher
priority.  This will break the module system, but will correspond to a
local definition of the derivation.

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