treewide: remove all cargoSha256 usage

[Aleksanaa]

Description of changes

First treewide (easy)

Treewide command:

find . -type f -name "*.nix" -print0 | xargs -0 sed -i 's/cargoSha256 = "sha256-/cargoHash = "sha256-/g'

Second treewide

Treewide bash script (which was executed in pkgs):

#!/usr/bin/env bash

process_line() {
    local filename=${1%:}
    if [[ $4 =~ \"(.*)\"\; ]]; then
      local sha256="${BASH_REMATCH[1]}"
    fi

    [[ -z $sha256 ]] && return 0

    local hash=$(nix hash to-sri --type sha256 $sha256)

    echo "Processing: $filename"
    echo "  $sha256 => $hash"

    sed -i "s|cargoSha256 = \"$sha256\"|cargoHash = \"$hash\"|" $filename
}

# split output by line
grep -r 'cargoSha256 = ' . | while IFS= read -r line; do
    # split them further by space
    read -r -a parts <<< "$line"
    process_line "${parts[@]}"
done

There are some exceptions, basically using a wrapped builder, or writing in let. I've manually fixed them. Would be better to check again.

buildRustPackage changes

I'm not really sure about this part.

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/)
• 24.11 Release Notes (or backporting 23.11 and 24.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.

[Aleksanaa]

Logically speaking it should not cause such rebuilds (or actually it will)?

[JohnRTitor]

Yeah, I am not sure if it's worth the rebuilding effort. Improvements like this can come atomically, like when updating that specific package.

[Aleksanaa]

Ah, I see. The hash here will not only be consumed by buildRustPackage, it also exists as an environment variable.

Improvements like this can come atomically, like when updating that specific package.

In theory we should deprecate it and avoid further usages altogether. We have already done that for golang's vendorHash (vendorSha256).

[h7x4]

Yeah, I am not sure if it's worth the rebuilding effort. Improvements like this can come atomically, like when updating that specific package.

I don't know about this. It feels like it's better to do a treewide into staging and let hydra take the hit once, rather than keep spending review time on it for random PRs. It will probably also make a higher percentage of new PRs use cargoHash, seeing how people often use another package as reference.

[Aleksanaa]

Once we have all treewide changes done, we can let it throw a warning, and let cargoSha256 a history. I'm currently considering completing other changes at the same time.

[Mic92]

Yeah, I am not sure if it's worth the rebuilding effort. Improvements like this can come atomically, like when updating that specific package.

Most of the time it won't make a difference because something else in staging will have caused the rust toolchain to rebuild from source anyway.

[Aleksanaa]

Oh the conflict is in staging, not master

[JohnRTitor]

LGTM, passes my eyeball test

[doronbehar]

Missed rust-analyzer, fix is at:

#326491