Is it ok to ask for `hash` attribute and SRI hash when reviewing PRs that update packages?

Development
1

Many PRs updating packages keep the sha256 attribute but use an SRI hash. Others replace an existing SRI hash with a sha256 hash again.

I understand that hash = "SRI-hash"; is the format nixpkgs is migrating to, so, is it OK to ask PR authors to use that format when helping with reviewing PRs?

Some big contributors do not do the change, and I feel like I would be overstepping, too, if I ask them.

2 Likes
2

My guess is, that quite often automatic tooling is used, that didn’t get updated yet.

Also: I was not aware that hash is prefered over sha256 now. I only was aware about the introduction and preference about lib.fakeHash over lib.fakeSha256.

So to spread the word, I am in favor of mentioning it in reviews, and point out where the deprecation is actually written down.

2 Likes
3

The issue is that hash is not supported by all fetchers and maybe it might be renamed in the future:

https://github.com/NixOS/nixpkgs/pull/79987#discussion_r378735698

4

But fetchgit supports hash since fetchgit: support hash parameter alongside sha256 · NixOS/nixpkgs@5c2b1b6 · GitHub

fetchurl supports it since years ago, and there is also cargoHash for Rust, and somebody added vendorHash for Flutter.

Go is still using vendorSha256, and like you said, some fetchers like fetchsvn do not support it, but I see the main ones, that already support it, being updated to hash slowly.