Flake auth versus derivation flexibility

when packaging some private repo go stuff recently it became apparent that the primary open source [recte unauthenticated] use cases make for really painful private repo ux. I will also note that this likely scales well to other languages, but I will speak to go, as I know it best.

if I am developing a go module, the language lists all of the upstream dependencies with cryptographic hashes, as required by the toolchain. as such, it is trivial to write either a fod that fetches all of them via script (what pkgs.buildGoModule does), an ifd that consumes the lock file (like pkgs.mkYarnPackage), or non-ifd magic that does the same (like naersk).

unfortunately, none of these play well with private repos. currently I have mirrored the behaviour that pkgs.fetchGitHub uses with its private flag, but this is beyond brittle on darwin, since those environment variables cannot persist across reboot.

on the flip side, flakes solve auth with a new access-tokens config parameter. this works great, and fetching github type flakes is simple. however, this only works for configured inputs, and because inputs is not full nix, we cannot say “I want inputs of all the repos listed in go.sum”. furthermore, this auth information is accessible within derivations, so we cannot “pass it down” to functions like pkgs.fetchGitHub or pkgs.buildGoModule.

I get that a lot of this is probably legacy, and an ask of flake maintainers may be to put all your dependencies as explicit flake inputs, but that quickly fails to scale: e.g. kubernetes would need 1300 inputs. is this a known issue? are there any suggested workarounds?

I’m also very much facing this @urandom have you ever found a decent solution to this problem?