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

Mathijs Kwik mathijs at bluescreen303.nl
Thu Jul 19 17:50:37 CEST 2012


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)?

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


More information about the nix-dev mailing list