add impureOverrides argument and overrideInputs to result

[adrian-gierakowski]

NOTE: this is a rebase and a slight refactor of https://github.com/NixOS/flake-compat/pull/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.