[Feature Request] Overwrite The Version of a Dependency's Dependency

[Embers-of-the-Fire]

Problem

This feature proposal is intended to allow setting the version of a dependency of a dependency.

Consider the following dependency graph:

• main
  • DepA v0.1.0
    • DepB v0.2.0
  • DepB v0.2.1

Currently, Cargo compiles two copies of the DepB crate, but in many real-world scenarios, we don't need to emphasize that the two use different versions. Thus, allowing overwriting of the version of a secondary dependency could theoretically be an effective way to save on compilation footprint; at the same time, since this behavior is done proactively, there are theoretically no unexpected serious bugs - after all, you can always drop this feature.
For an example in practice, imagine a library that provides some predefined data structures. Typically, these libraries implement the optional serde::Ser/Deserialize for their own data structures, which means that these libraries all need to include a serde. While differences in patches are handled by cargo, some minors or even majors that don't affect the implementation are not optimized.

Proposed Solution

Continue to follow the dependency diagram above. The syntax I envision is:

[dependencies]
DepB = "0.2.1"

[dependencies.DepA]
version = "0.1.0"
override-dep = { DepB = "0.2.1" }

This should be expressed as the following dependency:

• main
  • DepA v0.1.0
    • DepB v0.2.1 Reusing v0.2.1's DepB here.
  • DepB v0.2.1

Notes

All actual syntax and keywords are for demonstration purposes only. The FEATURE REQUEST simply raises the need for this feature. If this request is accepted, the proposer can participate in the implementation.

[weihanglo]

Consider the following dependency graph:

* main
  
  * DepA v0.1.0
    
    * DepB v0.2.0
  * DepB v0.2.1

Currently, Cargo compiles two copies of the DepB crate

Not for this example. Cargo will either resolves DepB to one SemVer compatible version, or error out, depending on the exact version requirements. This behavior is documented in this paragraph. You can also use the [patch] table to patch DepA if they have a unnecessary restricted version requirement.

It's hard to tell what the problem is upon a non-complete example. Do you mind sharing more details for the version requirements used there?

[weihanglo]

You might be interested in this issue #5640, and this might be a duplicate of that?

[Embers-of-the-Fire]

Not for this example. Cargo will either resolves DepB to one SemVer compatible version, or error out, depending on the exact version requirements. This behavior is documented in this paragraph. You can also use the [patch] table to patch DepA if they have a unnecessary restricted version requirement.

Sorry, I may not have expressed myself clearly. Currently Cargo is able to correct for patch differences. But there are times when minor or even major versions don't cause problems with the library, which is not semver safe behaviour, but I think some room for optimisation can be given with explicit user specification.

[Embers-of-the-Fire]

You might be interested in this issue #5640, and this might be a duplicate of that?

Haven't had time to read this issue carefully, if it is a duplicate then you can close my issue.

[weihanglo]

there are times when minor or even major versions don't cause problems with the library

Then it is #5640. Thanks for the report. Close in favor of #5640.