Including nixpkgs PRs for your system has never been easier!

Announcements
1

I made a flake that lets you seamlessly use nixpkgs pull requests before they hit your channel, check it out! GitHub - gepbird/nixpkgs-patcher: Using nixpkgs pull requests that haven't landed into your channel has never been easier!

You no longer need to wait for PRs get merged. … or for the merged PRs to land in your channel.
You no longer need to craft overlays to change package versions, or replace packages from a PR.
You no longer need to write disableModules and imports to use a NixOS module from a PR.
You no longer need to maintain your own fork of nixpkgs.

All you need is declaring a new flake input with the PR diff:

# file: flake.nix
{
  inputs.nixpkgs-patch-git-review-bump = {
    url = "https://github.com/NixOS/nixpkgs/pull/410328.diff";
    flake = false;
  };
}

Related discussions:

I’m aware there are similar tools to this (see GitHub - gepbird/nixpkgs-patcher: Using nixpkgs pull requests that haven't landed into your channel has never been easier!), the focus of nixpkgs-patcher is the ease of use for specifically patching nixpkgs for your personal system.

28 Likes
2

In addition to this module, there’s also a trick that @MattSturgeon taught me:

inputs.nixpkgs.url = "github:NixOS/nixpkgs?ref=pull/379731/merge";

This uses GitHub’s feature of concocting a tree with the PR merged against master.

16 Likes
3

I’ve written myself something similar with locally checked out patches after a while with GitHub - katrinafyi/nix-patcher: a tool for patching Nix flake inputs, declaratively! , I don’t remember exactly, but I think I had some issues with:

  • issues with naming and/or ordering of patches (sometimes they need to be applied in the correct order)
  • mutating references to patches: I was never sure I’d get the exact patch/PR version that I expected and I’m pretty sure this gave some issues when building configurations after some time has passed since the last flake update
    • caching those locally solved this issue for me

Didn’t dig much into how you’re doing the patching, but:

  • you might want to add ?full_index=1 to the examples, github likes to truncate the references to different lengths
  • does your solution work properly and reproducibly when referencing those mutating references? eg: PRs that are heavily worked on

PS: I love that you have also figured out and wrote down many different ways you can reference a patch on GitHub, was about to suggest my config.toml comments, but you seem to have it all :slight_smile:

1 Like
4

In this simple way you can only merge a single PR into its merge base, so that only covers the simpler use cases.

5

Thanks for sharing your solution and interest!

I don’t remember exactly, but I think I had some issues with:

  • issues with naming and/or ordering of patches (sometimes they need to be applied in the correct order)

With nixpkgs-patcher, patches get applied alphabetically, more info on ordering is at GitHub - gepbird/nixpkgs-patcher: Using nixpkgs pull requests that haven't landed into your channel has never been easier!

  • you might want to add ?full_index=1 to the examples, github likes to truncate the references to different lengths

That’s interesting, I see the index line in the diff is the full commit hash, but I don’t really see the value in that for typing those few characters out. When does github truncate it to different lengths? Is the same length not guaranteed when using the same URLs at different times?

  • does your solution work properly and reproducibly when referencing those mutating references? eg: PRs that are heavily worked on

With a URL like https://github.com/NixOS/nixpkgs/pull/410328.diff you can get different patches on different systems (however when it changes you’ll see that flake.lock is dirty), doing a nix flake update nixpkgs-patch-git-review-bump will get you the currently latest patch.

To ensure reproducibility, you can pin it to a specific commit hash, or a range of commits with compare and commit hashes like https://github.com/NixOS/nixpkgs/compare/b024ced1aac25639f8ca8fdfc2f8c4fbd66c48ef...0330cef96364bfd90694ea782d54e64717aced63.diff (after a force-push to the PR, IIRC GitHub should show that those commits don’t belong to any branch but still be available for download).

Another way to ensure reproducibility is use it with fetchpatch where you need to specify a hash and be sure that it will fail to build when the PR is updated, see GitHub - gepbird/nixpkgs-patcher: Using nixpkgs pull requests that haven't landed into your channel has never been easier!. Or download the patch locally and reference to it with path:./git-review-bump.diff to be extra sure. I’ll add a note about it to the readme, thanks :slight_smile:

1 Like