Set key for modules and nixosModules

[Atry]

Fixes NixOS/nixpkgs#340361

[roberth]

I'm slightly concerned about overridden inputs not being represented in the key, but this may be the lesser evil of the two.

[roberth]

Probably best to implement it anyway.

[roberth]

Coming to think of it, since we have this logic in two places now, it should be factored out, and since we're enabling new behavior, we should test it.

Specifically, eval-tests.nix should check that deduplication works (e.g. with a list-typed option that merges by appending, as usual), and that disabledModules works.

I won't have time for it in the coming days, so feel free to give it a shot.

[liarokapisv]

Hi there, can I help push this PR forward somehow?

[Atry]

Hi there, can I help push this PR forward somehow?

Feel free to hack on this

[liarokapisv]

@roberth Can't we use

inputsHash = builtins.hashString "sha256" (                                                                                                    
     builtins.toJSON (builtins.mapAttrs (_: v: v.outPath) self.inputs)                                                                          
);     

to also pin the inputs for the key?

[roberth]

It's not known which inputs and which transitive inputs matter to the behavior of the module, so that's still a heuristic, and a potentially costly one because you're also fetching inputs that may otherwise not be fetched.

I guess the good news is that the problem is still tractable and doesn't require fetching the whole input closure, but we'll have to be more clever about how we model this, and this will require Nix itself to help out a bit.

The behavior of a flake is determined by Nix itself, the lock file plus any overrides.

• Nix itself: can be ignored, because since the key contents aren't really for external consumption, we only care about the current evaluation, which is run by one Nix
• The lock file: can be read with outPath + "/flake.lock", unless the lock is edited in memory without using the overrides mechanism in call-flake.nix. We'd have to make sure it always goes through overrides or puts a virtual lock file in that place.
• The overrides: these are currently not accessible to the flake outputs function. Adding info about overrides is non-trivial and perhaps not something we even want user code to be able to observe. It seems preferable to perform the key computation in call-flake.nix instead, and only expose its value instead of the data that went into it.

I've opened NixOS/nix#14601 in nix so that we can work towards a real solution.