Overlay: reference pinned nixpkgs attr without infinite recursion?

Help
1

I frequently use an overlay to grab some package foo from a revision of nixpkgs other than what my NIX_PATH is pointing at, e.g.

self: super: {
  foo-pinned =
    (import (builtins.fetchTarball {
      url = "https://github.com/NixOS/nixpkgs/archive/bc94dcf500286495e3c478a9f9322debc94c4304.tar.gz";
      sha256 = "1siqklf863181fqk19d0x5cd0xzxf1w0zh08lv0l0dmjc8xic64a";
    }) { }).foo;
}

and adding foo-pinned to my system packages rather than adding foo.

I’d like to instead write the overlay like this:

let
  foo-pinned =
    (import (builtins.fetchTarball {
      url = "https://github.com/NixOS/nixpkgs/archive/bc94dcf500286495e3c478a9f9322debc94c4304.tar.gz";
      sha256 = "1siqklf863181fqk19d0x5cd0xzxf1w0zh08lv0l0dmjc8xic64a";
    }) { }).foo;

in self: super: {
  foo = foo-pinned;
}

allowing me to put foo (rather than foo-pinned) into my system packages.

Doing so, however leads to infinite recursion. Is there a cleaner way I could be doing this?

1 Like
2

This overlay is specified as part of the config that nixpkgs naturally looks for, right? so when you import the special nixpkgs, it also loads this overlay, hence infinite recursion. The content of the overlay depends on the content of the overlay. (This is why I prefer flakes :smiley:)

I don’t see a straightforward solution without changing the way you’re accessing and configuring nixpkgs normally, unless there’s a nixpkgs config option you could specify to the specially-imported nixpkgs that tells it to ignore local config.

3

According to the nixpkgs manual, it seems like passing { overlays = []; } instead of {} to the imported nixpkgs should override its automatic searching for overlays.

1 Like
4

That solved it. Thanks!

This is why I prefer flakes

Yeah, it certainly seems like flakes are the better way forward. I’ve held back on that so far partly because they’re still experimental (although it sounds like they’re pretty stable at this point?), but mostly because I haven’t yet taken the time to wrap my head around them and figure out how to migrate my config.

5

Fairly stable, for simple usecases. Complex input dependency structures, especially when the use of follows is involved, still have some bugs. The bigger problems that still need solving are more to do with establishing best practices that work well in terms of exactly how you expose functionality in the outputs. The current output schema has some significant deficiencies, like the inability to configure the nixpkgs instance used by a flake providing a package, or provide your own already-evaluated instance.