Why does this Nix SQLite overlay lead to recompiling Python 3.10 packages?

I created a repository to demonstrate the problem. Clone it and run nix develop. This will try to enter the devShell which has sqlite as an input. That in turn is modified through an overlay that adds a compile flag:

(self: super:
  sqlite = super.sqlite.overrideAttrs (oldAttrs:
    configureFlags = oldAttrs.configureFlags ++ ["--enable-dynamic-extensions"];
  });
})

You'll now find yourself going through this:

[1/2/241 built] building python3.10-cffi-1.15.1

this goes on for quite some time seemingly re-building the entire Python ecosystem.

The source for SQLite in the nixpkgs repository does reference python3Packages but I don't understand why this would recompile anything.

I also tried stubbing out the inputs using sqlite.override (_: { python3Packages = {}; }) but that has no effect on the recompilation. Stubbing out something like lib obviously breaks the build, so it seems the override clause itself is in effect.

Solution

See nix why-depends --derivation nixpkgs#python3Packages.cffi nixpkgs#sqlite (we use --derivation because we are concerned with build-time deps, not runtime deps):

/nix/store/i0h1pz3y6hn6zk5h01z2mn517gfn50h0-python3.10-cffi-1.15.1.drv
└───/nix/store/8zacqzz62px96vz3705kawrkhk3najhp-python3-3.10.12.drv
    └───/nix/store/dy3i053xjf62x8sd2yypz20cyg40mpp1-sqlite-3.42.0.drv

By changing sqlite, you have changed python3, and by changing python3, you have changed python3Packages.cffi.

The source for SQLite in the nixpkgs repository does reference python3Packages … I also tried stubbing out the inputs using sqlite.override (_: { python3Packages = {}; })

This is irrelevant, because, as noted in the comment, sqlite only uses python3 for tests that are not run during build. We can confirm by following the usage of python3Packages and finding it is only used in passthru, which is not part of the build. Regardless of that, it’s still irrelevant because sqlite is only using python3Packages there, and so not altering it in any way that would cause a rebuild of python3Packages. I.e., you were looking at the problem (and so the dependency graph) backwards.