Yeah, the Cargo.lock file means that * constraints aren&#x27;t a problem until you need to update a library, e.g. to get an emergency bug fix. And, you are right that cargo update&#x27;s --precise option allows manually getting the same benefits of explicit requirements, but even doing this once seems like more work than just including the right version, especially with the risk of `update`ing wrong (although, again, Cargo.lock can save you here, if you&#x27;re tracking it in version control). The combination of `cargo search` (built-in) and `cargo add` (external, others have linked it) makes it pretty easy to just add the right versions at the outset.<p><i>&gt; I&#x27;d also note that while theoretically restricting versions works, in practice having multiple versions of a single crate within a rust project often leads to build failures due to crate A having a public API that uses types from crate B, and crate C using both, but not getting the same version of B that A got. This leads to type errors at build time. </i><p>This <i>is</i> a problem, yes, but focusing on it by itself is somewhat of a red-herring: if A doesn&#x27;t restrict B&#x27;s version there&#x27;s no guarantee that A compiles against whatever version of B that happens to be chosen, i.e. you don&#x27;t even get to the point where there could be problematic interactions.<p>In any case, there has been serious discussion about how cargo can solve the problem of crates exposing other crates in their API, and the current proposed solution is to make cargo more strict about allowing multiple versions of such crates. #2064 is the relevant issue.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;cargo&#x2F;issues&#x2F;2064" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;cargo&#x2F;issues&#x2F;2064</a>