What I talk about is to rethink patched-nixpkgs. It is easy to distribute 6 lines of code, but it’s less fun when you have to amend/fit for any purposes.
So, there should be distribution format (smbd talked about flakes?), which is used to create a repo checkout. Even when someone does IFD nixpkgs, he creates repo checkout in /nix/store. Which is immutable, thus you can’t amend/inspect it. So skip this step, and instead of relying on IFD rely on script, which does “unwrap” of patched-nixpkgs spec into repo checkout.
The spec contains:
- base nixpkgs checkout rev (is it true that most patched-nixpkgs use includes fetching nixpkgs by rev?)
- patch spec itself (or revision revert spec)
- patch description, either meta.description or as comment. It’s easy to get lost in unnamed patches
The spec should be autogenerated from existing repo checkout. Something like
git log origin/master..HEAD | preprocess >> spec.nix
$ # patched-nixpkgs is a script that performs download of nixpkgs and
# applies patches from spec on top of it and publish as local channel
$ nix run nixpkgs.patched-nixpkgs patched-nixpkgs --channel mynixpkgs -f nixpkgs-spec.nix
# then you can use <mynixpkgs> - no need to IFD
$ nix run nixpkgs.patched-nixpkgs patched-nixpkgs --dir $PWD/mynixpkgs -f nixpkgs-spec.nix
# then you can export NIX_PATH=nixpkgs=$PWD/mynixpkgs
$ nix run nixpkgs.patched-nixpkgs patched-nixpkgs --shell -f nixpkgs-spec.nix
# now you enter a subshell, which has NIX_PATH set for you. Similar to nix-review
One extra step to deployment, but no more IFD. I think NixOps can be taught to do same for each spec.
The approach proposed by @basvandijk will force users to use this API for patched-nixpkgs, but those users will soon give-up it because maintenance of patches isn’t rewarding it’s benefits. I’m very surprised you @volth get little troubles.
Another hurdle is Github down events. By using patched-nixpkgs spec and IFD it may ruin your deploys.