Allow mutitple SemVer-compatible version with = exact requirement

[andrewbanchich]

Problem

Adding multiple exact (=) versions of the same crate which Cargo considers semver compatible will produce a dependency conflict.

[dependencies]
foo = "=1.2.0"
foo_old = { version = "=1.1.0", package = "foo" }

error: failed to select a version for `foo`.
    ... required by package `rusttest v0.0.1`
versions that meet the requirements `=1.1.0` are: 1.1.0

all possible versions conflict with previously selected packages.

  previously selected package `foo v1.2.0`
    ... which satisfies dependency `foo = "=1.2.0"` of package `rusttest v0.0.1`

failed to select a version for `foo` which could resolve this conflict

Is this a technical problem, or is it Cargo thinking it knows better than me because those two versions should be semver compatible?

If it's the latter, I would consider this a bug.

Steps

See above

Possible Solution(s)

No response

Notes

No response

Version

No response

[weihanglo]

1.1.0 and 1.2.0 are considered SemVer-compatible. Cargo allows only one Semver-compatible version per package. Copied from the discussion:

A compromise that was made way back at the beginning of cargo.
One version per package, like Python, ends up to strict. Dependency hell.
As many versions as needed, like NPM, ends up with blote. And errors of the form can not use foo as foo
The compromise was keep more than one copy as long as the copies are not semver compatible

Cargo strictly follows SemVer. I would recommend remove = requirement as they should be compatible, otherwise they should be released under SemVer-incompat versions. See this chapter for more info on SemVer compatibility.

[andrewbanchich]

I have a use case for doing this, so what I'm currently forced to do is vendor the package code and rename it to something else. That would have the same issue with dependency bloat, right?

[weihanglo]

Could you share more details of your use case? That's a better way to move forward. Changing the behavior requires an RFC, as the comment states.

Without knowing the details, as I see it. The author of the package may misuse SemVer. You can also consider patching the package if possible.

[andrewbanchich]

I'm working on a way to detect breaking changes in dependencies. Patch releases can include behavior changes in APIs, but because they're bugfixes they are considered compatible. What's more, semver is just a pinky promise.

In order to write tests for migrating from one minor / patch version to another, I need to include both in a binary and compare results.