-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
zig build dependencies: name the hash function used in the manifest #14284
Comments
Nix uses Does it make sense to support more than one hashing method? Earlier it was popular to have md5+sha1. |
i also prefer the latter one line version |
When we start phasing out sha256 far in the future, transitional period may be easier by using two hash functions simultaneously. Perhaps we should consider a format that can support multiple hashes for the same artifact. Therefore, if we do this:
Implies that there is only a single hash, or multiple fields in the same section are allowed.
Like others, I agree that having algorithm+hash on the same line makes sense: one cannot live without the other, and don't bloat the line too much. |
There is multihash. It encodes the hash algorithm + the hash size in a binary format. That would make it more difficult for the user to tell which format it is from the file. Anyway, I think it's at least worth considering including the hash size along with the algorithm like multihash does. |
If using ZON, it'd be pretty neat to support multiple hashes like: .hash = {
.sha256 = "bfac1bf4e5ab32b7a2cc424bf35b2eade5b783757a90d3108a4173bb1684dbe9",
.md5 = "965cc7027c64265a2e4bd602dfcc85b1",
}, In this case having only one hash function can simplify to the oneliner: .hash = { .sha256 = "bfac1bf4e5ab32b7a2cc424bf35b2eade5b783757a90d3108a4173bb1684dbe9" }, |
I implemented multihash already, if anyone wants to rip it for use here. https://git.sr.ht/~gcoakes/zig-multihash |
Extracted from #14265.
Currently the build.zig.ini file uses:
This is a SHA-256 hex-encoded digest. This proposal is to change it to:
Or perhaps:
Idea being to leave room for an upgrade to a different hash function in the future.
The second form may be preferred in order to ease copy+pasting from an error message, and so that diffs of hashes are only one line each.
Another possible syntax would be to use
_
instead of=
which would allow hashes to be used as field names in #14290 without use of@""
syntax.The text was updated successfully, but these errors were encountered: