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

[Mathijs Kwik]

On Thu, Jul 19, 2012 at 11:09 PM, Nicolas Pierron
<nicolas.b.pierron at gmail.com> wrote:
> 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.
>
I see.
Indeed, my extensions don't use rec either, because they use the
altered version of callPackage.

This sounds like a great idea to implement. It would indeed be great
to just provide a list of sources to nixos or nixpkgs, and have them
get mixed/combined into 1 set accessible through callPackage or as a
variable representing the unified set.

I will play with your solution a bit, probably with some
modifications, and if it works without problems, try to fabricate a
nice pull request to discuss here :)


> 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/