Override inputs when using builtins.getFlake

[raboof]

Is your feature request related to a problem? Please describe.

Sometimes it can be cumbersome to refactor a derivation to 'pass in' a flake input, for example when you're working with a 'classic' nix system or the derivation you want to modify is somewhere 'deep'. In these cases the getFlake builtin comes in handy.

getFlake, however, strictly honors the flake.lock of whatever you got. If that refers to something big, such as nixpkgs, this might lead to different versions of that dependency in your store.

Describe the solution you'd like

It would be nice to be able to 'pass in' inputs to getFlake, similar to input.nixpkgs.follows = "nixpkgs" in flake.nix or --override-input on the nix commandline.

Priorities

Add 👍 to issues you find important.

[rrix]

this is making using software distributed as flakes from a "legacy" configuration.nix or a non-flake project essentially impossible, especially if your system isn't running on unstable:

error: Python version mismatch in 'python3.10-arcology-0.1.0':

       The Python derivation 'python3.10-arcology-0.1.0' depends on a Python derivation
       named 'python3.10-arroyo_rs-0.1.0', but the two derivations use different versions
       of Python:

            'python3.10-arcology-0.1.0' uses /nix/store/c3cjxhn73xa5s8fm79w95d0879bijp04-python3-3.10.13
           'python3.10-arroyo_rs-0.1.0' uses /nix/store/pzf6dnxg8gf04xazzjdwarm7s03cbrgz-python3-3.10.12

       Possible solutions:

         * If 'python3.10-arroyo_rs-0.1.0' is a Python library, change the reference to 'python3.10-arroyo_rs-0.1.0'
           in the propagatedBuildInputs of 'python3.10-arcology-0.1.0' to use a 'python3.10-arroyo_rs-0.1.0' built from the same
           version of Python

         * If 'python3.10-arroyo_rs-0.1.0' is used as a tool during the build, move the reference to
           'python3.10-arroyo_rs-0.1.0' in 'python3.10-arcology-0.1.0' from propagatedBuildInputs to nativeBuildInputs

         * If 'python3.10-arroyo_rs-0.1.0' provides executables that are called at run time, pass its
           bin path to makeWrapperArgs:

               makeWrapperArgs = [ "--prefix PATH : ${lib.makeBinPath [ arroyo_rs ] }" ];

        at /home/rrix/Code/nixpkgs/pkgs/development/tools/poetry2nix/poetry2nix/default.nix:427:11

I'm very close to ripping flake.nix out of all of my projects and distributing them classically, rather than going "all-in" on flakes.

[benaryorg]

Adding this feature would also allow e.g. a Hydra jobset to have an additional job which overrides the flake input to point at a more current version (e.g. to automatically test against the current nixpkgs from a non-flake job with a regular git input which uses builtins.getFlake and overrides).
Any other solutions like building a derivation that runs nix flake update with --override-input (which is already hell of a stretch in usability) falls flat due to the is not allowed to refer to a store path constraint while also requiring IFD via e.g. builtins.path to even get to that point.

The usual approach of working around this by creating a parent flake which overrides the input as mentioned by OP also does not work programmatically since any flake created within Nix at runtime will be a store path, and anything created before runtime has effectively the same issue of being potentially outdated at runtime.