How do I customize my own repo with an overlay?

Help
1

I’m a bit shaky on the application of overlays and would appreciate help.

I have my own repo of a few nix packages.
In the repo’s file structure they are in a folder called ./pkgs/ and have their own subfolders.
At the toplevel I have a ./default.nix syndicating them all.
That already works how I want it to, as in I can build it with nix-build ./default.nix and install packages from it e.g. with nix-env -iA package1 -f ./default.nix.

The default.nix looks something like:

{ pkgs ? import <nixpkgs> {} }:
rec {
  package1 = pkgs.callPackage ./pkgs/Package1 {};
  # ...
  package9 = pkgs.callPackage ./pkgs/Package9 { Package1 = package1 };
}

Now, I want to have ./another_default.nix, that I can build with nix-build ./another_default.nix
It should just apply the following single overlay and otherwise just do what the original does:

self: super:

{
  package1 = (super.package1.override {
    defaultTerminal = self.pkgs.urxvt;
  });
}

How would ./another_default.nix look like?

Background: default.nix is what I would check into the repo, another_default.nix
has just a small, private customization that is .gitignore'd.

2

I don’t know if you can apply an overlay to anything but nixpkgs.

Maybe an alternative is have another_default.nix declare package1 then merge the contents with default.nix

You can use //

Return a set consisting of the attributes in e1 and e2 (with the latter taking precedence over the former in case of equally named attributes).

1 Like
3

You could use makeExtensible for that.

Here is your default.nix altered with makeExtensible:

{ pkgs ? import <nixpkgs> {} }:

pkgs.lib.makeExtensible (self: {
  package1 = pkgs.callPackage ./pkgs/Package1 {};
  # ...
  package9 = pkgs.callPackage ./pkgs/Package9 { Package1 = self.package1 };
})

And here is another_default.nix using extends:

(import ./. {}).extend (self: super: {
  package1 = (super.package1.override {
    defaultTerminal = self.pkgs.urxvt;
  });
})

Note that self.pkgs will only work if you inherited pkgs in one of those files.

2 Likes
4

Hehe, nix-build segfaults, when I try your solution @aszlig

5

That overwrite the package in the toplevel, but not for package9 in my example which also depends on package1.

6

Oh really? Do you have a more minimal example on how to reproduce it?

7

I think it was the very debugging , that caused the segfault. I had a “stdenv.lib.traceVal defaultTerminal” in ./pkgs/package1 from before your post, when I was trying things. If take it out, stuff builds. With it it takes a minute or so not printing anything, then it segfaults. My guess would be, the traceVal does some kind of memory allocation and causes the overlay to recurse infinitely. Allocation segfaults before the thing hits the recursion limit or something, if that is at all plausible.