I am using `overridePackages` for a similar purpose already. (Simplified for ease of presentation.)
One top-level file ties the overlays together and serves as a replacement for `<nixpkgs>`. `mynixpkgs.nix`: ``` nix { machine }: let pkgs = import <nixpkgs> { }; machineOverlay = { machineA = import ./machineA.nix; machineB = import ./machineB.nix; }.${machine} or (throw "unknown machine: ${machine}!") ; extends' = lhs: rhs: self: super: let super' = rhs self super; in super' // lhs self (super // super'); inherit (pkgs.lib) foldl' flip; in pkgs.overridePackages ( foldl' (flip extends') (_:_:{}) [ (import ./extraPkgs.nix) machineOverlay # ... ] ) ``` I can add my own private packages in their own overlay layer. `extraPkgs.nix`: ``` nix self: super: with self; { foo = callPackage ./foo { }; bar = callPackage ./bar { }; } ``` And I can add machine specific settings in another overlay layer. `machineA.nix`: ``` nix self: super: with self; { boost = super.boost.override { mpi = openmpi; }; fftw = super.fftw.overrideDerivation (attrs: { configureFlags = attrs.configureFlags ++ [ "--enable-avx" ]; }); foo = (super.foo.override { # Some machine specific parameters }).overrideDerivation (attrs: { # Some machine specific attributes }); } ``` `machineB.nix`: ``` nix self: super: with self; { # Different machine specific settings. } ``` Having such an overlay mechanism built into nixpkgs would simplify this pattern. I would welcome such a change. Best, Andreas _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev