On Thu, Jul 19, 2012 at 11:09 PM, Nicolas Pierron <[email protected]> wrote: > On Thu, Jul 19, 2012 at 8:50 AM, Mathijs Kwik <[email protected]> > wrote: >> On Thu, Jul 19, 2012 at 5:40 PM, Nicolas Pierron >> <[email protected]> wrote: >>> On Thu, Jul 19, 2012 at 6:03 AM, Mathijs Kwik <[email protected]> >>> wrote: >>>> On Wed, Jul 18, 2012 at 7:12 AM, Nicolas Pierron >>>> <[email protected]> wrote: >>>>> On Mon, Jul 16, 2012 at 12:32 AM, Mathijs Kwik <[email protected]> >>>>> 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/ _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
