Dev-dependencies affecting release build

I'm building zoxide 0.8.3 with admittedly outdated vendored crates. However the only crate that's behind is rstest referred in dev-dependencies:

[dev-dependencies]
assert_cmd = "2.0.0"
rstest = { version = "0.15.0", default-features = false }
rstest_reuse = "0.4.0"
tempfile = "3.1.0"

Now is that expected that cargo build --release fails with:

error: failed to select a version for the requirement `rstest = "^0.15.0"`
candidate versions found which didn't match: 0.13.0

since rstest shouldn't be needed during this phase?

dev-dependencies section doesn't mean "only in non-release build" - it means "only for building the tests/examples/benchmarks". They must be resolved anyway.

I realize that but my point is why cargo resolves unused dependencies? I would expect it resolves rstest during cargo test but cargo build does not event attempt to build rstest. I can drop it from dev-dependencies and cargo build will pass just fine.

Before building anything Cargo makes a lock file with all dependencies for all features on all platforms. If it can't make the lock file, it can't build.

This is a leftover from original Cargo logic, now known as resolver = "1" that did not see any difference between dev and normal dependencies and resolved them all together. Now resolver = "2" can look at only necessary dependencies, but the lock file is still for everything all at once.

4 Likes

Thanks @kornel for clarification. Do you happen to know if there are any plans to make lock file "dependencies" more granular or is it likely to stay?

I haven't heard of such plans. It will probably stay, because lock files are supposed to guarantee you can always build the project, and excluding dev builds from this guarantee weakens this promise. The lock files are also kept long term in projects, so need to have a stable format.

Perhaps Cargo could be persuaded to add a build mode or dependency resolution mode that skips the lock file and forces it to ignore broken dependencies.