update-source-version: update cargo hash if exists

[usertam]

Let gitUpdater work with rustPlatform.buildRustPackage; if $attr.cargoHash exists, update it.

Current behavior

If we do something like

rustPlatform.buildRustPackage {
  ...

  passthru.updateScript = gitUpdater {
    rev-prefix = "v";
  };

  ...
}

we would get error like

nixpkgs/pkgs/build-support/rust/hooks/cargo-setup-hook.sh

Lines 68 to 76 in 97dc21f

	echo "ERROR: cargoHash or cargoSha256 is out of date"
	echo
	echo "Cargo.lock is not the same in $cargoDepsCopy"
	echo
	echo "To fix the issue:"
	echo '1. Set cargoHash/cargoSha256 to an empty string: `cargoHash = "";`'
	echo '2. Build the derivation and wait for it to fail with a hash mismatch'
	echo '3. Copy the "got: sha256-..." value back into the cargoHash field'
	echo ' You should have: cargoHash = "sha256-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=";'

because cargoHash was never updated.

Why now?

Since #349360 is here, rust packages no longer bundle their flake.lock inside nixpkgs and now their cargoDeps only depend on cargoHash, making updates much easier to automate.

Difference from original hash replacing logic

I copied most of the hash updating behavior from the original script, but 1) default to replacing a fake sha256 hash as I see no one using sha512 in cargoHash; and 2) skipped non-SRI-style hash handling since cargoSha256 is deprecated:

nixpkgs/doc/languages-frameworks/rust.section.md

Lines 52 to 59 in fb65bbf

	::: {.warning}
	`cargoSha256` is already deprecated, and is subject to removal in favor of
	`cargoHash` which supports [SRI](https://www.w3.org/TR/SRI/) hashes.
	If you are still using `cargoSha256`, you can simply replace it with
	`cargoHash` and recompute the hash, or convert the original sha256 to SRI
	hash using `nix-hash --to-sri --type sha256 "<original sha256>"`.
	:::

Testing

I only tested this against firecracker so far. Appreciate if other maintainers can test on their rust packages also. 🙏

diff --git a/pkgs/by-name/fi/firecracker/package.nix b/pkgs/by-name/fi/firecracker/package.nix
index 293c9057a..8adab8d0b 100644
--- a/pkgs/by-name/fi/firecracker/package.nix
+++ b/pkgs/by-name/fi/firecracker/package.nix
@@ -2,6 +2,7 @@
   lib,
   stdenv,
   fetchFromGitHub,
+  gitUpdater,
   cmake,
   gcc,
   rust-bindgen,
@@ -75,6 +76,11 @@ rustPlatform.buildRustPackage rec {
     runHook postInstall
   '';

+  passthru.updateScript = gitUpdater {
+    rev-prefix = "v";
+    ignoredVersions = "dev";
+  };
+
   meta = with lib; {
     description = "Secure, fast, minimal micro-container virtualization";
     homepage = "http://firecracker-microvm.io";

Open to suggestions, whether this is something needed or not; or if this should be implemented somewhere else and not polluting the update-source-version.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[jtojnar]

Thanks.

Personally, I think I would prefer to keep the tool simple and with as little magic as possible.

Alternative would be using update script combinators, see e.g. librsvg. Currently, it is a bit unwieldy but we could create a function that would hide this complexity and could be used something like passthru.updateScript = _experimental-update-script-combinators.cargoDepsUpdateCombinator (gitUpdater {…})

And if one is not allergic to heuristics-oriented tools, there is also nix-update-based nixUpdateScript.