I’m checking out the overlay page on the nixos wiki, and it refers to making overlays that apply a patch. It gives the example of modifying the package ‘sl’, by adding a ‘patches’ attribute:
final: prev:
{
sl = prev.sl.overrideAttrs (old: {
patches = (old.patches or []) ++ [
(prev.fetchpatch {
url = "https://github.com/charlieLehman/sl/commit/e20abbd7e1ee26af53f34451a8f7ad79b27a4c0a.patch";
hash = "07sx98d422589gxr8wflfpkdd0k44kbagxl3b51i56ky2wfix7rc";
})
# alternatively if you have a local patch,
/path/to/file.patch
# or a relative path (relative to the current nix file)
./relative.patch
];
});
}
How does one created a patch of the correct format for that? I’ve tried this before and had it not work. I normally never use patches so that’s unsurprising. How exactly does one make a patch for a package in nixpkgs? I’d probably opt for the relative patch.
My specific need right now is to apply an overlay so that the current yt-dlp package looks like the one from master.
patches is to patch the programs sourcecode. If you want to override the derivations src, then you override the derivations src, not patches. Though as far as I remember, overriding a python packages sources requires some other techniques that I have absolutely no insights into.
If you’re trying to patch nixpkgs, the way to apply the patch would be using something like pkgs.applyPatches, or using your own custom fork/branch.
In this case I would just use .overridePythonAttrs (equivalent of .overrideAttrs but for python packages) and, yknow, override the attrs that you want to override, don’t use a patch.
Ok well that explains a lot. I thought the patch the documentation was discussing was for the nix code in nixpkgs, but actually its trying to apply it to the yt-dlp code being fetched from github.
Good to know about .overridePythonAttrs. I got started on modifying the attrs with this but its rather a hassle compared to just diffing a file, IMO. Maybe next time, since I noticed that the yt-dlp version in 25.11 is newer than the version in unstable! I guess unstable isn’t always the latest.
Any any rate, yt-dlp is working again, crisis averted.
When a PR is applied to unstable and immediately backported to stable, as happens often with rapidly-moving targets like yt-dlp, it’s fairly common that the change hits stable before unstable, just because unstable often takes longer to make it through CI. It’s a bit counterintuitive, but that’s just how things come out.