The second example is fine, the first example I somewhat disagree with.
I actually prefer to avoid another instance of nixpkgs (but obviously this is situational), and I’ve yet to find a better solution than either an overlay or manually calling callPackage again.
It’s easier to see where the package is from, eval is faster and uses less RAM,
“Easier to see” - maybe so, but you’d have to do proper benchmarking to claim the latter. I think you’ll find that that’s not true, since IIRC someone on this forum did some benchmarking on overlays and found minimal impact.
If you enjoyed this you’ll probably also enjoy “1000 instances of nixpkgs”
I think you misunderstood that post; creating an entirely new nixpkgs instance for one package is frankly silly, yet that’s exactly what happens when we use your code in the first example.
Hmmm I think you might’ve missread the first example? At no point in the two examples I’m arguing are better is a new instance of nixpkgs being created (the closest to that that happens is actually the overlay example that causes an additional recompute of the nixpkgs fixed point before it can be used, which is exactly the reason I’m arguing against doing that). What I’m arguing there is that instead of using overlays to recompute your whole instance of nixpkgs you should instead use callPackage to just make that individual package you want to use. That is what the example code I showed in there ends up doing under the hood. My point is that you should prefer making multiple package sets (nixpkgs being one among them) over using overlays to layer multiple package sets together on top of your nixpkgs instance.
Edit: Well okay yea actually you’re right that with the inputs.abpkgs.${pkgs.stdenv.hostPlatform.system}.abapp example you’re likely to compute a second instance of nixpkgs for that package specifically. I would argue that that means you should prefer the later import inputs.abpkgs pkgs which ends up as just a bunch of callPackage calls under the hood
Which requires upstream to expose a default.nix that takes pkgs as an arg, which basically no one does. (There’s no standards.) Sure, if upstream supports it, that’s probably fine.
Unfortunately, everything depends on stdenv and co which requires nixpkgs.
Also, for cross-compilation using an overlay becomes even more imperative.
My main point though is that I also used to believe that overlays were heavy, but the empirical data have convinced me otherwise. They’re complex for beginners but not necessarily for nix.