Ch14.03 Unclear description of dependency versions across a workspace

[tpdickson]

• I have checked the latest main branch to see if this has already been fixed
• I have searched existing issues and pull requests for duplicates

URL to the section(s) of the book with this problem:
https://doc.rust-lang.org/stable/book/ch14-03-cargo-workspaces.html#depending-on-an-external-package-in-a-workspace

Description of the problem:
The book states that the top-level Cargo.lock file in a workspace ensures that all crates in the workspace use the same version of dependencies. It uses the crate rand as an example. It further states the same thing again, and that "no additional copies of rand will be downloaded." I've set the adder crate to use rand 0.7.3 and the add_one crate to use rand 0.8.3, then built the workspace. In my workspace's Cargo.lock file, there is now rand 0.7.3 and rand 0.8.5, and the output log on cargo build showed that it compiled the second version of rand.

Suggested fix:
The current text is either not clear enough to describe how dependency versioning is handled within a workspace, or the description is incorrect. I don't know what the correct behavior should be, but what I'm seeing from my workspace is contradicting what I'm reading in the book.

[zetaraku]

Yeah, it seems that dependencies in the same workspace can have different versions.

[skorobogatydmitry]

That's still takes place in the latest version of the book. I've tried to specify different version of rand and cargo downloaded a 2nd package. I think that behavior is correct, as large projects might need to have dependencies version skew during transition and Cargo.lock tracks different package dependency versions.
Although, the book misleads on that

Cargo has ensured that every crate in every package in the workspace using the rand package will be using the same version <...>

I believe it should be reworded to underline that Cargo reuses dependencies across the workspace where possible.

[chriskrycho]

I agree that we should clarify this! I will think on how we might tweak the wording here—either by using a "*" specifier specifically, or by noting that it will keep them aligned if they are compatible, or both—since the "*" specifier, which is increasingly best practice for workspaces, is a specific case of “if they are compatible.”