Cargo fails to select next higher pre-release version

help
1

There are several issues with this error message, and I have tried fixes I could think of like comparing features. Still the dependency resolution error persists:

error: failed to select a version for `holochain_types`.
    ... required by package `holochain_client v0.4.4`
    ... which satisfies dependency `holochain_client = "^0.4.4"` of package `testrs023 v0.1.0 (/Users/jost/Desktop/holochain/testrs023)`
versions that meet the requirements `^0.2.2` are: 0.2.2

all possible versions conflict with previously selected packages.

  previously selected package `holochain_types v0.2.3-beta-rc.0`
    ... which satisfies dependency `holochain_types = "^0.2.3-beta-rc.0"` of package `holochain v0.2.3-beta-rc.1`
    ... which satisfies dependency `holochain = "^0.2.3-beta-rc.1"` of package `testrs023 v0.1.0 (/Users/jost/Desktop/holochain/testrs023)`

failed to select a version for `holochain_types` which could resolve this conflict

Steps to reproduce are:

  • cargo new deps_res_error
  • cd deps_res_error
  • insert
holochain_client = "0.4.4"
holochain = { version = "0.2.3-beta-rc.1" }
holochain_types = "0.2.3-beta-rc.0"
mr_bundle = "0.2.2"

under [dependencies] into Cargo.toml.

  • cargo check

holochain_types is not pinned in holochain_client, but set to `0.2.2.

I expect cargo to select holochain_types v0.2.3-beta-rc.0 automatically as the next higher patch version, but it doesn't. Why does it not do that?

2

A colleague has resolved the mystery. Cargo doesn't automatically select pre-release versions.

Meaning that 0.2.3-beta-rc.0 will not be considered. It needs explicit specification for pre releases.

3

colleague here :slight_smile:

i wanted to dig a little deeper and see if it's possible that we could specify the supported versions, including future pre-releases, in the consumer.

either i'm misunderstanding the documentation or there is a bug in the semver crate.
the following is the result of playground code i constructed:

use semver; // 1.0.18

fn main() {
    let mut i = 0;
    for version_req in ["0.2", "0.2.3", "0.2.2, 0.2.3-0"] {
        let version_req = semver::VersionReq::parse(version_req).unwrap();
        for version in ["0.2.2", "0.2.3", "0.2.3-beta-rc.0", "0.2.3-beta-rc.1"] {
            let version = semver::Version::parse(version).unwrap();
            println!(
                "[{i}] does {version_req} match {version}? {}",
                version_req.matches(&version)
            );
            i += 1;
        }
    }
}

[0] does ^0.2 match 0.2.2? true
[1] does ^0.2 match 0.2.3? true
[2] does ^0.2 match 0.2.3-beta-rc.0? false
[3] does ^0.2 match 0.2.3-beta-rc.1? false
[4] does ^0.2.3 match 0.2.2? false
[5] does ^0.2.3 match 0.2.3? true
[6] does ^0.2.3 match 0.2.3-beta-rc.0? false
[7] does ^0.2.3 match 0.2.3-beta-rc.1? false
[8] does ^0.2.2, ^0.2.3-0 match 0.2.2? false
[9] does ^0.2.2, ^0.2.3-0 match 0.2.3? true
[10] does ^0.2.2, ^0.2.3-0 match 0.2.3-beta-rc.0? true
[11] does ^0.2.2, ^0.2.3-0 match 0.2.3-beta-rc.1? true

i expect [8] to match as it specifies ^0.2.2 as one of its comparators. what am i missing?

4

Versions valid for 0.2.2, 0.2.3-0 are the intersection between the versions valid for 0.2.2 and 0.2.3-0. 0.2.2 is not a valid version for the 0.2.3-0 requirement, so it's not a valid version for the intersection either. Specifying the patch number tells Cargo you will not accept an older version even if it was compatible.

https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html

Here are some more examples of version requirements and the versions that would be allowed with them:

1.2.3  :=  >=1.2.3, <2.0.0
5

Neither using "0.2" nor ">=0.2, <0.3" work for this case. The version resolver simply doesn't consider these pre-release versions.

6

thanks Heliozoa. i didn't think that the version requirements specify an intersection. however i double-checked the SemVer::matches implementation and in simplified terms it applies a logical AND to all individual comparator matches. from the documentation i was expecting and hoping for a logical OR.

unfortunately this means that we can't construct a single VersionReq that matches different minor versions as well as their pre-releases.