The naive idea being that this would help with consistency and, at least, minimize the size of the product by avoiding having multiple versions of nikpkgs being pulled in.
If this is at all useful, then
Is there a smarter way of doing it than trying to list everything manually?
How should you discover other, less obvious, inputs that might be shared?
I depends on the flake, if the rust overlay for instance just exposes an overlay then you won’t need the follows since the overlay will be applied to your “main” nixpkgs input anyways, I don’t think flake-compat depends on nixpkgs at all, flake-utils claims to be pure nix and thus shouldn’t require nixpkgs either.
You need to do that anyway, because there is no guarantee nixpkgs is actually called nixpkgs in the upstream flake. There’s currently no way to avoid a cursory glance at a dependency flake’s inputs to my knowledge (and arguably you should take that glance anyway because you’re installing arbitrary code from GitHub). Thanks @kamadorueda
Personally, I manually set a follows for each input’s nixpkgs, as well as other flakes that would be duplicated. This could cause breakage, but would be obvious at compile time and is easy to undo. If you’re not sure which flakes may duplicate something, a look through flake.lock can be a nice way to assert that down the line.
I agree this isn’t ideal though, it causes a fair bit of boilerplate, and might be unmaintainable if flakes become more fragmented one day. I’d love to know whether this limitation is intentional, since it is very reminiscent of how nix handles package dependencies; just without the easy self-references to undo the exponential version growth where appropriate.
