This is related to the question in Multiple versions of dependency in project. That post asked how a crate can depend on two different versions of a library and get access to types exported by that library.
My case is probably easier: I have a crate
version-sync that depends on
url = "1.5.1". The crate used to compile fine with Rust 1.17, but because of a newly published version of
unicode-normalization, my crate no longer compiles with Rust 1.17.
Note that I didn’t change anything in my code – the code just stopped compiling because of a release of a transitive dependency. Anyhow, the question of how to indicate that the minimum required version of Rust has changed is being discussed in the api-guidelines repository.
In the meantime, I would like to hear what actually happens when a crate pins a dependency. I’m considering updating the
Cargo.toml for my little project with
[dependencies] unicode-normalization = "=0.1.5"
version-sync crate doesn’t actually use
unicode-normalization at all, it’s an implementation detail of the
url crate. Does that make it safe to pin the version like this?
If another crate
foo depends on my crate, will
foo be able to depend on a newer version of
unicode-normalization? I would like to avoid causing downstream problems for crates that depend on my
I’ve seen that Rust mangles symbols when compiling, so will a final compiled binary simply contain the
unicode-normalization symbols and code twice under different names?
What happens if
unicode-normalization would pull in a huge dependency tree – will the code of these dependencies end up in the binary twice, or can the compiler “join” the dependency graphs again?
Thanks in advance for any insights!