Use a location of cudd with a stable git hash.#399
Conversation
|
CC: @maliberty note, once this is submitted, the name of that dependency will change. |
Using archive links from github is dangerous as they can change any time, as they build them on-the-fly, so hashing the file can create unstable hashes: https://github.blog/open-source/git/update-on-the-future-stability-of-source-code-archives-and-hashes/ (Unlike for instance nix, bazel does not hash the content of a tar but the binary tar.gz itself, so it is prone to run into the issue) Fix that by using another source that is providing the tar.gz itself, so is stable. Note: this will change this dependency from `@com_github_ivmai_cudd` to `@com_github_davidkebo_cudd`
5738100 to
5a8f873
Compare
|
This one library has a source tar that avoid the issue but the use of GH archives seems to be endemic (eg https://github.com/bazelbuild/bazel-central-registry/blob/main/modules/boost.array/1.87.0/source.json). |
|
yes, it is a big problem actually in many projects, but I try to avoid it as much as possible. Given that boost is in active development and we will probably update it often enough that we don't reach the instability-of-hash horizon (as github guarantees to keep it stable for a while), we might not run into that easily. But the mature and stable |
|
Diff'd these archives offline and they are identical. |
Using archive links from github is dangerous as they can change any time, as they build them on-the-fly, so hashing the file can create unstable hashes: https://github.blog/open-source/git/update-on-the-future-stability-of-source-code-archives-and-hashes/ (Unlike for instance nix, bazel does not hash the content of a tar but the binary tar.gz itself, so it is prone to run into the issue) Fix that by using another source that is providing the tar.gz itself, so is stable. Note: this will change this dependency from `@com_github_ivmai_cudd` to `@com_github_davidkebo_cudd`
Using archive links from github is dangerous as they can change any time, as they build them on-the-fly, so hashing the file can create unstable hashes:
https://github.blog/open-source/git/update-on-the-future-stability-of-source-code-archives-and-hashes/
(Unlike for instance nix, bazel does not hash the content of a tar but the binary tar.gz itself, so it is prone to run into the issue)
Fix that by using another source that is providing the tar.gz itself, so is stable.
Note: this will change this dependency from
@com_github_ivmai_cuddto@com_github_davidkebo_cudd