Semver issue between rand, rand_core 0.4.0 and rand_core 0.3.0

[Eijebong]

Have a Cargo.toml like that,

[dependencies]
rand = "0.6.5"
rand_core = "0.4.0"

cargo build runs as expected.

After a cargo update -p rand_core:0.3.1 --precise 0.3.0 though, cargo build fails with:

error[E0277]: the trait bound `rand_hc::Hc128Rng: rand_core::SeedableRng` is not satisfied
   --> /home/eijebong/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:282:5
    |
282 | /     fn from_seed(seed: Self::Seed) -> Self {
283 | |         StdRng(rngs::StdRng::from_seed(seed))
284 | |     }
    | |_____^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Rng`

error: aborting due to 31 previous errors

rand_core 0.4 should probably be updated to depend on rand_core 0.3.1 at least and released as 0.4.1 (might be worth to yank 0.4.0 after that).

[hcpl]

cc #754.

[dhardy]

rand_core 0.3.1 depends on version 0.4. Version 0.3.0 should automatically be updated to version 0.3.1; you're seeing this error because you prevent that.

Sure, we could solve this problem by always making new versions depend on the previous version, but that would force most users to depend on many versions simultaneously (0.4.0 → 0.3.1 → 0.2.2). The current model only causes users of old versions to depend on multiple versions of the crates, and only causes issues (a) for people with a dated Cargo.lock file who then somehow also depend on the latest version and must then run cargo update and (b) for people like you who force use of older versions for some reason(?).

[nox]

You misunderstood the problem though: if you want to do compatibility shims like that, you have to propagate the 0.3.1 version as a minimum bound through all of the other rand crates too.

E.g. rand_chacha shouldn't be depending on rand_core >=0.2 <0.4, but on rand_core 0.3.1.

In general, no amount of cargo update even with --precise arguments should lead to build errors.

[dhardy]

E.g. rand_chacha shouldn't be depending on rand_core >=0.2 <0.4, but on rand_core 0.3.1.

The last published version of rand_chacha is 0.1.1 published on Jan 4th. rand_core versions 0.3.1 and 0.4.0 were published on Jan 25th. Even if we publish a new version of rand_chacha dependent on rand_core 0.3.1 (for whatever reason; I have no idea) this doesn't force people to use the latest version of rand_chacha. (If we do publish a new version of rand_chacha, likely it would use the latest version of rand_core, 0.4.0, anyway.)

In general, no amount of cargo update even with --precise arguments should lead to build errors.

I don't believe we could do this except (a) by making all users of the latest version also depend on the previous version or (b) by yanking previous versions (which still doesn't force existing users to update, but does at least make it harder to use).

[GregBowyer]

FYI for those of us using build systems like bazel, this is a hard build breaker as there is no sane semver way of including the same dep with different versions.

This gives me a bunch of fails under bazel that are effectively impossible to resolve

[dhardy]

@GregBowyer if using only the latest versions, or if using an older version and avoiding the compatibility shims (rand_core 0.2.2 and 0.3.1, also last rand 0.3.x IRC), you still don't need to use multiple versions.

The compatibility shims are there because Cargo does allow multiple versions, but doesn't unify them: if crate A provides an RNG "ARng" using rand_core 0.3's RngCore, and crate B wants an R: RngCore using rand_core 0.4, then without a compatibility shim Rust would simply complain "ARng doesn't implement RngCore".

What the ideal solution to this is, I don't know. Never allowing multiple versions of the same crate would actually be easier for us, but might cause more build issues in general. Allowing certain crates to opt-out from multiple version usage may be better, but still not perfect.

[Eijebong]

The issue is not about having multiple versions of the same dependency AFAICT, it's about Rand 0.6 depending on core 0.4.0 not explicitly depending on 0.3.1.

IMHO you should've released core 0.4.1 depending on 0.3.1 and made Rand require 0.4.1 (it's a lot of version numbers so I might be confused/wrong)

[dhardy]

rand_core version 0.4.x cannot depend on 0.3.x because 0.3.1 depends on 0.4.0 and cycles are not allowed.

[dhardy]

I know our current approach here does have some short-comings, but it is essentially just @dtolnay's semver trick, and I don't believe there is a better approach.

I think therefore we should close this issue? It does seem like people are running into problems here quite often, but this may just be due to the popularity of the Rand crate.

[vks]

We could consider creating a FAQ, but I'm not sure whether that helps.