Cargo pulling multiple versions

[ajayrathore]

Hi,
My Cargo.toml looks like this

[package]
name = "mylib"
version = "0.1.0"
edition = "2018"

[dependencies]
rkdb = "0.4.0"
avro-rs = "0.7.0"
schema_registry_converter = { git = "https://github.com/gklijs/schema_registry_converter" }
kafka = "0.8.0"
failure = "0.1.5"
serde = { version = "1.0", features = ["derive"] }
lazy_static = "1.4.0"

[lib]
name = "mylib"
crate-type = ["cdylib"]

[profile.release]
opt-level = 3
debug = true
rpath = false
lto = false
debug-assertions = false
codegen-units = 1

When I run cargo build, somehow its pulling avro-rs-0.9.0, how can I enforce Cargo to only pull the version defined in Cargo.toml?

~/code/Rust/mylib(master ) cargo build --release
Updating crates.io index
Updating git repository https://github.com/gklijs/schema_registry_converter
Downloaded smallvec v1.4.0
Downloaded serde_json v1.0.52
Downloaded libc v0.2.69
Downloaded syn v1.0.18
Downloaded cc v1.0.52
Downloaded typenum v1.12.0
Downloaded backtrace-sys v0.1.36
Downloaded ryu v1.0.4
Compiling cc v1.0.52
Compiling libc v0.2.69
Compiling syn v1.0.18
Compiling typenum v1.12.0
Compiling ryu v1.0.4
Compiling smallvec v1.4.0
Compiling unicode-normalization v0.1.12
Compiling getrandom v0.1.14
Compiling rand v0.4.6
Compiling socket2 v0.3.12
Compiling nix v0.11.1
Compiling idna v0.2.0
Compiling rand_core v0.5.1
Compiling url v2.1.1
Compiling rand_chacha v0.2.2
Compiling backtrace-sys v0.1.36
Compiling libz-sys v1.0.25
Compiling openssl-sys v0.9.55
Compiling curl-sys v0.4.30+curl-7.69.1
Compiling miniz-sys v0.1.12
Compiling generic-array v0.12.3
Compiling rand v0.7.3
Compiling synstructure v0.12.3
Compiling rkdb v0.4.0
Compiling digest v0.8.1
Compiling uuid v0.8.1
Compiling twox-hash v1.5.0
Compiling openssl v0.10.29
Compiling curl v0.4.28
Compiling backtrace v0.3.46
Compiling flate2 v0.2.20
Compiling error-chain v0.10.0
Compiling kafka v0.8.0
Compiling serde_derive v1.0.106
Compiling failure_derive v0.1.7
Compiling zerocopy-derive v0.2.0
Compiling strum_macros v0.18.0
Compiling typed-builder v0.5.1
Compiling failure v0.1.7
Compiling zerocopy v0.3.0
Compiling serde v1.0.106
Compiling serde_json v1.0.52
Compiling avro-rs v0.9.0
Compiling avro-rs v0.7.0
Compiling schema_registry_converter v2.0.0 (GitHub - gklijs/schema_registry_converter: A crate to convert bytes to something more useable and the other way around in a way Compatible with the Confluent Schema Registry. Supporting Avro, Protobuf, Json schema, and both async and blocking.)

[Cerber-Ursi]

If some crate uses functionality from avro-rs 0.9, you simply can't give it 0.7 - this version might not have the necessary API at all.

[daboross]

It looks like schema_registry_converter is the origin of the dependency - since it depends on version = ">= 0.6", cargo will by default just pick the latest version which matches its constraints.

To manually tell cargo to downgrade schema_registry_converter's dependency on avro_rs to 0.7.0, I believe you can use some extra arguments to cargo update:

cargo update -p avro-rs:0.9.0 --precise 0.7.0

This tells cargo to update anything depending on the package avro-rs with version 0.9.0, and ask it to use version 0.7.0.

That should downgrade it, and it will persist that choice in Cargo.lock.

Unfortunately, cargo really likes to force the latest version, so you'll need to use this command again next time you cargo update. If you check in your Cargo.lock, as is standard for binary programs, though, and watch the changes when you update, it should be possible to keep in check.

---

For investigating similar things, I recommend looking into Cargo.lock directly. It holds all of the information about why cargo makes its decisions, and is actually pretty readable. To find the info for this post, I searched for "avro-rs" in Cargo.lock, saw that schema_registry_converter depended on it, and then looked at schema_registry_converter's Cargo.toml to see what exact version it depended on.

Since most major version bumps (like 0.8 to 0.9) introduce breaking changes, package dependencies like >= 0.6 are pretty rare. But if you ever run into this again in the future, it should be possible to resolve by poking around Cargo.lock and potentially using a manual cargo update.

[Michael-F-Bryan]

You may also be able to use the cargo-outdated tool to figure out which crates are using outdated dependencies.

I've found this works pretty well when you're trying to figure out where multiple versions of the same crate are coming from, it's also easier than trawling through Cargo.lock manually.

[anlumo]

cargo-tree also helps a lot with finding dependencies.

[ajayrathore]

Thanks all for the suggestions.
This works perfect for me

cargo update -p avro-rs:0.9.0 --precise 0.7.0