I recently came up with a certain pattern of maintaining and using patched flake input branches.
After a few days of using this pattern I decided it seems useful enough to share.
The documentation is currently under a heading in my infra repo readme.
I may have missed or mis-evaluated some of the benefits and costs involved 
I hope some of you will find it useful and/or inform me of how I have messed up.
What do you see as the benefit of having it as a monorepo vs a traditional “fork” if it’s all on GitHub
(or to be more specific a different Git remote).
I heard Lix supports applying patches ontop of Flakes; if we merge that into CppNix, you can keep the patch files in the infra repo and apply them without changing the url of the remote which is a pattern I like.
(I find maintain patch files easier to see how I diverged from the upstream vs. a different remote which can get confusing quickly if the history isn’t always linear)
It’s a single-repo setup. There’s less to keep track of, more self contained. And a fork repo doesn’t have to exist. My goal was to formalize this. And doing so means finding “the way” or “the simple way”. Requiring more repositories to exist didn’t seem like a reasonable ask. And then I realized git is flexible…
Hey if Nix provides such a feature I’d be the first to use it.
That looks very interesting, thank you for sharing.
(hope you don’t mind me hijacking the thread a tiny lil bit to shill what I did to achieve a similar goal)
Personally I use a system for monkey-patching nixpkgs specifically because sometimes I just want to use that one PR that isn’t merged yet. The whole thing is then applied by the flake (or non-flake, I’m doing some weird reverse flake-parts thing there).
Note: links are IPv6-only
The goal was specifically to be able to reference individual patches to basically cherry-pick, which does not require any repository or fork at all (other than the invoking code), however it does rely on IFD which brings its own issues.
I don’t want to host a fork, and I want to be able to combine individual patchsets, and I have not yet found a suitable solution that can provide this (i.e. something offering an automatically rebased and patched version of an upstream branch via e.g. git, which would be cool), and that’s even after looking at other exotic systems like pijul which treat patches differently than git does.
The MVP was basically to have stdenv.mkDerivation { patches = [ ... ]; src = nixpkgs.outPath; } as nixpkgs which worked pretty well.
I am considering to move the monkey-patching into its own Hydra build (I self-host Hydra) so that I can use them as direct dependencies and track the output and differences, which would not get rid of IFD, but it would allow the IFD output to be cached properly by the binary cache.
That’s news to me (though I’m not actively looking around for these things), do you have any reference to that since I can’t seem to find it.?