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
HDI version references break now that there's 0.X.X versions #1596
Comments
Here is the full:
|
thinking this through, i suspect it's also not an entirely effective workaround. the only way i see is that we pin all dependencies in the hdi and all its local dependencies recursively. all else leaves wiggle room for the resolver. @Connoropolous i would appreciate your thoughts on this. |
thinking about build reproducibility, which is the ultimate desired outcome for happ builds, the hdi crate relates to this as follows:
|
Symptoms
See the comment below, with the full output
Steps to reproduce
cargo init
a new cargo crateset
hdk = "0.0.152"
as a dependencyrun
cargo build
.Analysis
This hasn't previously been an issue when using
0.0.X
dependencies because every version was treated as incompatible with other 0.0.X versions, due to being the left-most non-zero number.holochain/crates/hdk/Cargo.toml
Line 30 in f026430
cargo
actually resolves this to0.1.3
when 0.1.3 has been released, or 0.1.4 when that's released, etc.I had already dealt with the same or similar thing in holochain-open-dev/dna-auth-resolver and it's an issue that comes up when you change to using
minor
versions in SemVer from just usingpatch
versions.I had to analyze this confusing situation we had, and found this:
https://doc.rust-lang.org/cargo/reference/resolver.html#semver-compatibility
I've done some digging... in the cargo dep resolution book:
"Versions are considered compatible if their left-most non-zero major/minor/patch component is the same. For example, 1.0.3 and 1.1.0 are considered compatible, and thus it should be safe to update from the older release to the newer one. However, an update from 1.1.0 to 2.0.0 would not be allowed to be made automatically. This convention also applies to versions with leading zeros. For example, 0.1.0 and 0.1.2 are compatible, but 0.1.0 and 0.2.0 are not. Similarly, 0.0.1 and 0.0.2 are not compatible."
That part at the end is key.
"Similarly, 0.0.1 and 0.0.2 are not compatible."
It also says:
"If multiple packages have a common dependency with semver-incompatible versions, then Cargo will allow this, but will build two separate copies of the dependency. "
Fix Suggestion
switch to
=0.1.2
or equivalentUpdate
I figured out that in the short run we can workaround this with this command:
but that will not be easy or intuitive for anyone to figure out
The text was updated successfully, but these errors were encountered: