Nix Overrides That Expire Themselves

Nix Overrides That Expire Themselves

July 30th, 2026

| Warsaw, Poland

Subscribe

I recently published yesod-form-1.7.10 to Hackage. My project gets all of its<br>dependencies from nixpkgs, and nixpkgs gradually adopts Haskell packages from<br>Hackage. That means that there’s some time between when the package lands in<br>nixpkgs, and when I need to use the package in my project, which is right now.

You can write an override in your flake.nix to get the newer package you<br>need, but what happens when you eventually bump the nixpkgs version and the<br>override is made redundant? There’s nothing by default which warns you that the<br>override should be removed.

A colleague of mine showed me this pattern which makes the override announce<br>its own obsolescence. When Nix evaluates the flake, it compares package<br>versions and warns when the version is greater than or equal to the version in<br>your override.

packageOverrides = prev.lib.composeExtensions prev.haskell.packageOverrides<br>(hfinal: hprev: {

# we require 1.7.10 for runFormPRG; the pinned nixpkgs only has<br># 1.7.9.2.<br>yesod-form =<br>let<br>noOverride =<br>prev.lib.versionAtLeast hprev.yesod-form.version "1.7.10";<br>in<br>prev.lib.warnIf noOverride ''<br>yesod-form >= 1.7.10 is now in nixpkgs, the override can be removed.<br>''<br>(if noOverride then<br>hprev.yesod-form<br>else<br>prev.haskell.lib.dontCheck (hfinal.callHackageDirect<br>pkg = "yesod-form";<br>ver = "1.7.10";<br>sha256 = "sha256-9TqA7c2djVaLvrj/rj47LiJ7D1rLbrGhi585FvD9zRE=";<br>{ }));<br>});

In this example, hprev.yesod-form.version is whatever the pinned nixpkgs<br>provides. The lib.versionAtLeast function compares version strings, and<br>lib.warnIf is the part that prints a message during evaluation when the<br>condition is true.

So, when it’s time to remove the override, you’ll see something like this:

evaluation warning: yesod-form >= 1.7.10 is now in nixpkgs, the override can be removed.

This approach isn’t specific to package versions. You can do this anywhere you<br>have an override where the justification for the override can be expressed<br>conditionally. For example, we also use this to clean up overrides where a<br>package was marked as broken in nixpkgs, and is subsequently un-marked.

markUnbrokenWithWarning = p: nixpkgs.lib.warnIfNot p.meta.broken ''<br>Package ${p.meta.name} is no longer broken.<br>The corresponding override can be removed.<br>''<br>(markUnbroken p);

When someone eventually fixes the package upstream and the broken flag is<br>removed, the warning tells us to delete the workaround.

nix