Flake: inputs.<name>.patches = []

[blaggacao]

Is your feature request related to a problem? Please describe.
I'm very frustrated to have to aggregate two (2) PRs on input-output-hk/haskell.nix manually and on a fork.

• manually is cumbersome, but if I was expected to go the extra mile I could do. (egoistic argument) — also consider the flake's diff's terseness when "healing" as PRs get merged.
• on a fork is malign since a consumer of my flake can not easily infer that the quality of my fork is that of a work around for patch aggregation. (social argument of conserving public good faith)
• Workarounds like this [for nixpkgs only] are "horrible" (search for patch in that file and discover how involve [and brittle] it is — basically re-triggers an evaluation of nixpkgs in the wrong circumstances).

Describe the solution you'd like

# proposal-ish - please read while gracefully complementing & subsanating

{
  inputs.nixpkgs = {
    url = github:NixOS/nixpkgs/nixos-20.03;
    patches = [
      "https://url.example.com/some.patch" # allow to use current "special url" syntax
      # but also fall back to proper flake-input-ish attribute sets
      { rev = "​abctgf657​"​; }  # same remote commit
      { ref = "​ref/pr/123​"​; } # same remote PR
      {
        type = "​github​"​;
        org = "myfork"​; # different remote
        repo = "​nixpkgs​"​;
        ref = "​​abctgf657​​"​;
      }
      {
        type =​ "​file​"​; # a single (patch) file from somwhere
        urL =​ "​https://url.example.com/some.patch​"​;
        flake = false​;
      }
    ];
  };
}

# evaluation fails, if merge fails
# flake.lock pins patches (especially refs) as if they where regular inputs

How to resolve merge conflicts or a broken aggregate remains the user's problem. In that case user needs to step down from these facilities and fork (and just use plain git alongside).

Describe alternatives you've considered

• Fork — it's a) cumbersome and b) misleading — see above
• some nixery (whichery with nix) in the output body which is completely out of consideration because it would additionally impart:
  • cumber
  • initelligable - ness
  • semantically poor (patches to input's source trees are inputs themselves, sic!) - ness

Additional context

• Similar request Support flake references to patches #3920 (on wrong issue template) — I opened this here to be concise and clear.
• https://discourse.nixos.org/t/flake-patch-inputs/10854
• My gut tells me the commonality threshold is reached so in order to offload those user's facilities to nix (cost-benefit-positive)
• It positively impacts the terseness of flakes (see semantic gain above)
• In case conflict resolution is required on a fork, a branch naming convention of say aggregate-whatever can increase semantic terseness beyond the limitations of this proposal (so do suggest a convention it in the docs)

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/flake-patch-inputs/10854/4

[garbas]

closing this issue in favor of #3920

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/improving-flakes/12831/50