treewide: switch to cargoHash

[Aleksanaa]

Description of changes

No need (observed) for these packages to have a vendor Cargo.lock. If they for some reason have to use a different Cargo.lock than upstream, they should copy that to the build directory as well, otherwise the build will fail. They don't, so I infer there's no reason to use Cargo.lock.

Related #327063

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.

[emilazy]

I think we could quite tractably automate this treewide: hook into postPatch, output a hash of the Cargo.lock file, and compare against the Cargo.lock in‐tree?

[jopejoe1]

Looking at the history of some of them shows that they had git dependency's at some point but did not switch away from vendoring Cargo.lock files after those where no longer included.

[minijackson]

I don't mind either way for my package, but shouldn't we wait for consensus on #327063 before?

[Aleksanaa]

I don't mind either way for my package, but shouldn't we wait for consensus on #327063 before?

I believe we've never made consensus on "regular rust packages should also use Cargo.lock" (no git dependencies, no cargo lock hacks), it is always considered as an anti-pattern

[minijackson]

Was it always? For a while I thought cargoHash was the anti-pattern, due to the reasons I mentioned in #327063

[Aleksanaa]

Was it always? For a while I thought cargoHash was the anti-pattern, due to the reasons I mentioned in #327063

https://nixos.org/manual/nixpkgs/unstable/#rust

As the documentation shows, using cargoHash is the recommended way. It however mentioned two kinds of situations where cargoLock should be used: 1. in a project itself 2. contains git hashes.

[Mic92]

Was it always?

Yes. Otherwise we would have replaced all cargo hashes already. The size of the lock files was always a concern.

[felschr]

As maintainer for nickel, I'm good with the change. Similar to the other cases, it was only introduced due to git dependencies upstream which aren't required anymore:
https://github.com/NixOS/nixpkgs/pull/255266/files#r1327205689

[minijackson]

Welp, I might have given to much importance to some random messages on the Nixpkgs issue tracker, then. But if that's the case, I do think it's worth updating the documentation. I do see cargoHash being presented first, but nowhere do I see it being explicitly recommended over lockFile in nixpkgs. Even after re-reading it, I just see the documentation presenting two ways of doing things, each with their pros and cons.

[Mic92]

Welp, I might have given to much importance to some random messages on the Nixpkgs issue tracker, then. But if that's the case, I do think it's worth updating the documentation.

Be my guest.