The rust dependency hell has no end. Update redox_users (because Firefox builds on redox, you know /s) to get rid of two versions of rand_core, and now you get a new version of base64 via the upgrade of rust-argon2.
Conversation
I suspect some more focused effort on getting some core ecosystem crates to 1.0 would go a long way. Also a list of targets to include /exclude for the purposes of dependency resolution would be great.
1
How would a 1.0 push affect this kind of issue?
2
in the *specific* case of rand, the reason it breaks the ecosystem so often is that it uses the semver hack and also it's declared that it still wants to change the API, so 1.0 is a proxy for "we're mostly done now"
1
2
Well it does the semver hack, which is fine it's what lets serde stay at 1.0.x, but it does it *badly*. For instance 0.7 was released of rand with an accompanying breaking change that should of made rand-core bump x (0.x.y) but instead it did a bump of y. Both 0.6 and 0.7 resolve
1
1
to the new version and well that's incompatible with 0.6. For such a fundamental crate it really does not get the care and oversight it needs. It, libc, and some other crates used pretty much everywhere really should figure out their desired api, and get out a 1.0
1
2
That being said rust dependency duplication is a far better problem to have over Haskell's self imposed semver hell of "One package version to rule them all". I've lost literal days to that one.
1
4
Very much this. Having recently attempted to convert a Haskell package from stack to cabal-v2 and failing to figure out the right version bounds, I can definitely say I prefer allowing multiple versions of the same crate like cargo does.