add impureOverrides argument and overrideInputs to result

[adrian-gierakowski]

NOTE: this is a rebase and a slight refactor of #49, since that PR as bit-rotten

1. allows to override specific top level input by providing a "path" (relative or absolute)
2. any type of input can be overriden
3. follows which point at overridden input's inputs are not modified
   for example, given inputs a and b, and a.inputs.nixpkgs.follows = "b/nixpkgs", when b gets overridden, a's nixpkgs will remain unchanged

This is not necessarily the final solution but I created the PR so we have a starting point that "works" as we iterate towards something acceptable

I'm going to quote @roberth's comment from the other PR as a starting point for further discussion

The Nix CLI with --override-input does seem to respect follows, whereas this only replaces a specific input relation.

I'm also concerned that this limited feature creates friction for a more generalized or "compliant" version of the same feature.

Furthermore I believe there's significant tech debt in flake-compat that makes it harder to see a more general solution; an over-reliance on the arbitrarily named nodes.*.

cc @Mic92 @ckiee @Eveeifyeve

[adrian-gierakowski]

@roberth

Furthermore I believe there's significant tech debt in flake-compat that makes it harder to see a more general solution; an over-reliance on the arbitrarily named nodes.*.

Do I understand correctly that this comment is about current implementation of flake-compat (not this PR specifically)? Can you elaborate on this? How does the native nix implementation differ in this regard from flake-compat?

[roberth]

Yes, it is about the overall state of the projects, but I do believe it affects our ability to reason about inputs due to most of it being centered around nodes instead, which are not a suitable abstraction for anything except following the lockfile verbatim.
They are definitely very similar in their approach though. I think most of the differences should be possible to boil down to fetching polyfills instead of fetchTree and a different public interface for how to invoke the thing.

[adrian-gierakowski]

The Nix CLI with --override-input does seem to respect follows, whereas this only replaces a specific input relation.

I did a quick test and it is indeed the case.

So to replicate this flake-compat we'd have to re-implement the flake locking logic (currently implemented in c++) in nix. Not sure how much effort that would be. Ideally we'd need a shared test suite to make sure that the behaviour is and stays the same. Is this worth the effort?

Personally I have flake enabled and the reason I was interested int this in the first place, is that I consume flakes in non-flake projects, and builtins.getFlake doesn't allow overrides. So the it seemed like the easiest path would be to add it here. In fact I'm currently using a fork of flake-compat with this silly one-liner patch, which took me 5 minutes to implement and dose the job for my use case.

[roberth]

This is mostly summarizing the previous discussion.

Unexpected semantics

The semantics of this overrideInputs feature differ fundamentally from nix --override-input:

1. Does not respect follows: As noted in discussion, native --override-input propagates overrides through follows declarations. This implementation only replaces the specific input relation. Given a.inputs.nixpkgs.follows = "b/nixpkgs", overriding b leaves a's nixpkgs unchanged.
2. Only affects top-level inputs: The rootOverrides mapping only considers lockFile.nodes.${lockFile.root}.inputs, so nested input overrides aren't possible.

Unclear Path Towards General Override Support

This PR concerns me in light of NixOS/nix#7730, which will significantly change how call-flake.nix (nix's implementation which is mirrored here) resolves transitive inputs.

Having a separate reinvention of that solution would be a liability, but we can use flake-compat to prototype nix#7730 so that it can adopt the same solution in call-flake.nix.

Any override mechanism we add now should be designed with this trajectory in mind. The current implementation is tightly coupled to the flat nodes.<id> structure, which nix#7730 will not be.

[roberth]

Unintentional debug trace?