+1 from me, we need to plan out the details such as deprecation timeline (involving dates and docs).
I'll review the PR. On Tue, Dec 27, 2016 at 8:43 PM, Benno Fünfstück < benno.fuenfstu...@gmail.com> wrote: > Hi Nicolas, > > I like the idea of Nixpkgs overlays. I have not thought fully about the > whole proposal (and I need to catch up with how security updates work > first), but I think there is small mistake when you say: > > As part of this modification, I intend to remove the > `pkgs.overridePackages` function, as this one can literally be > replaced by the following Nix expression: > > ```nix > let pkgs = import <nixpkgs> {}; in > import pkgs.path { overlay = [ (self: super: { > foo = super.foo.override { enableBar = true; }; > bar = import ./pkgs/bar { inherit (self) stdenv fetchurl foo; }; > }) ]; } > ``` > > > The `overridePackages` function is useful when you want to chain multiple > functions that modify the package set, like > > ```nix > let > pkgs = import <nixpkgs> {}; > pkgsA = functionA pkgs > pkgsB = pkgsA.overridePackages (super: self: { > }); > ``` > > In this code example. I do not need to know how functionA is implemented > internally. It seems to me that, if I instead used overlays for this, it > would be hard to achieve the same effect: I would have to manually take > care to re-apply the overrides that `functionA` put in place. > > This does not mean that `overridePackages` needs to stay as-is. But > perhaps it would be possible to implement it using overlays, while still > providing the same interface to the user? > > > Regards, > > Benno Fünfstück > > > _______________________________________________ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > >
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev