build(nix): drop support for outdated nixpkgs revisions #402
Conversation
Require nixpkgs to have a 1.2.0+ umu-launcher package.
MattSturgeon
force-pushed
the
nix/drop-old
branch
from
670905f to
4d33ffd
Compare
|
1.2.0+ has been available in all unstable nixpkgs channels since 2025-02-24, so just over a week now. IDK how long we wanted the grace period to be, where users are allowed to have out-of-sync umu & nixpkgs inputs, but I'm going to undraft this now. As outlined in the description above, the grace period for this does not need to be anywhere near as long as the renames introduced in #345. |
|
Did pyzstd get back ported to stable? I don't think umu is in stable either until 25.05 is released |
This PR isn't dropping stable nixpkgs support, because that was never supported to begin with. The flake requires an unstable nixpkgs input that contains an overridable What the PR drops is support for nixpkgs unstable inputs that contained the older umu-launcher package where more things needed to be overridden. The newer umu-launcher package in nixpkgs is basically identical to this flake, so we're only overriding |
Summary
#374 added support for nixpkgs revisions containing umu-launcher 1.2.0+, this PR drops support for nixpkgs revisions with older versions of the umu-launcher package.
Changes
pyzstd.nixold-unwrapped.nixversionAtLeast "1.2.0"assertionNew assertion
The new assertion will likely remain indefinitely, with its minimum version being bumped whenever the downstream nixpkgs package adds some implementation detail that our flake package depends on. If the downstream package ever adds something we depend on without bumping its version, the assertion would have to check that explicitly, e.g. by checking what attributes exist on the package.
As an example of the error message users would see, you can view this PR's CI failure from before the lockfile was updated 😁
Grace period
This PR was initially a draft, because we want to grant end-users a grace period where their nixpkgs and umu inputs are allowed to be out-of-sync.
The grace period here shouldn't need to be very long though, unlike the renames done by #345. Those renames could trip up users who don't update their inputs often; some users likely still haven't updated their inputs since before #345.
In contrast, a user updating their umu input without updating their nixpkgs input is less likely. Also, the assertion message should be enough to detect and help resolve the issue.
cc @beh-10257 @LovingMelody @R1kaB3rN