cargo includes two versions of crate when one is enough

[tspiteri]

For example num-bigint has a dependency on rand >= 0.3.14, < 0.5.0. If I create a crate with the following dependencies:

[dependencies]
num-bigint = "0.1.43"
rand = "0.3.14"

and run cargo update, I would expect one version (^0.3.14) of the rand crate. Instead, Cargo.lock contains two versions, 0.3.160.3.22 for the crate, and 0.4.2 for num-bigint. This leads to incompatible types. (Edit: bad example in this comment.)

[matklad]

Hm, I wonder why 3.16 is picked? Rand 3.22 reexports rand 4, and that should resolve incompatibilities.

[tspiteri]

Oops, I picked a bad example as rand 0.3 does indeed reexport 0.4. A better example:

[dependencies]
malloc_buf = "1"
libc = "0.1"

The malloc_buf has a dependency on libc >= 0.1, < 0.3. So any version 0.1.* would satisfy both, but malloc_buf is given libc 0.2. In the case of malloc_buf, libc is not part of the public API (I think), so it is not really an issue.

In my case I was working on a crate which exposes *mut libc::FILE. Specifying a dependency on libc >= 0.1 < 0.3 is not enough to be compatible with both libc version 0.1 and 0.2: a crate depending on libc 0.1 would have an 0.1 *mut FILE which is incompatible with the 0.2 *mut FILE from my crate. If cargo just reused 0.1 for my crate, the problem would be solved.

[matklad]

Out of curioucity, why do you need to support libc 0.1? Transition to libc 0.2 happened long ago...

In general, we now advice against using <= deps in the libraries: this use case is better covered by the same trick as rand uses: old major version reexports types from new major version.

[tspiteri]

My aim was to not introduce unnecessary constraints, but yeah, libc 0.2 happened back in 2015, so in this case it isn't an issue in practice. I only reported the issue because I wasn't aware of any recommendations against >= x, < y deps, so I thought this same issue might crop up elsewhere.

[matklad]

Yeah, it is indeed the case that Cargo could do a better job at unifying dependencies here. It was discussed a lot in the context of pub/private dependencies, and that surprising conclusion was that we probably should just nudge the ecosystem in the direction of always using plain foo = x.y.z requirements, because this is what you actually almost always want for libraries.

The issue about linking against non-trivial requirements: #5340, closing in favor of that.

Thanks for the report! Major version striding is actually an interesting case here, and it’s interesting to get confirmation that semver trick actually works!