Unable to check for updates when latest versions conflict

[kornelski]

cargo-outdated can't show any version information if Cargo finds a conflict with the latest versions.

In my case:

• criterion required lazy_static ~1.1
• lazy_static 1.2 exists

If a project uses lazy_static on its own, this creates a conflict between criterion's 1.1 and the latest 1.2.

As a result, cargo-outdated fails and can't show any version information.

[leoschwarz]

So this issue is about

[dependencies]
lazy_static = "1.2"
criterion = "=0.2.7"

i.e. even cargo update would fail to resolve the dependencies due to conflicting requirements?

Or is it a more intricate issue with conflicting transitive dependencies/lock files? (I ask because I have a similar issue but apparently cargo update seems to work there.)

[leoschwarz]

Actually my issue boils down to

[dependencies]
tiff = "=0.2.0"
byteorder = "*"

cargo update thinks it's fine but cargo outdated fails.

[kornelski]

Yes, it's a case where even Cargo would fail to resolve the dependencies.

(criterion has updated its deps since, but the problem in general remains)

[leoschwarz]

I see. (In that case the second example I've just posted might be a different issue to do with asterisk specifiers, 1.3.*.)

If semver compatible updates are not the goal or to be disabled optionally (see #134) then I wonder if setting the version specifier to "*" transitively for all dependencies might fix this issue too. I guess in the case of a conflict which even cargo update cannot resolve this is more or less the best we could do here. Cargo already does a relatively good job at explaining the conflicts.

[RalfJung]

I think I am running into this issue as well:

$ cargo outdated -R
error: failed to select a version for `ring`.
    ... required by package `cookie v0.11.0`
    ... which is depended on by `rocket_http v0.4.0`
    ... which is depended on by `rocket v0.4.0`
    ... which is depended on by `rocket_contrib v0.4.0`
    ... which is depended on by `ff-node-monitor v0.1.0 (/tmp/cargo-outdated8Z3aQx)`
versions that meet the requirements `^0.13.0` are: 0.13.5

the package `ring` links to the native library `ring-asm`, but it conflicts with a previous package which links to `ring-asm` as well:
package `ring v0.14.6`
    ... which is depended on by `ff-node-monitor v0.1.0 (/tmp/cargo-outdated8Z3aQx)`

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

This is a regression: I have just updated cargo-outdated, and before the update, this exact same repository would work just fine for cargo-outdated. Unfortunately I don't know which version number I came from, but it was old.

[jbg]

I have a dependency on ring v0.14.6 and can’t use cargo outdated now that a newer version of ring has been released. Multiple versions of ring can’t be linked into the same program (briansmith/ring#535), and something to do with the way that cargo outdated figures out what is outdated triggers that issue:

error: failed to select a version for `ring`.
    ... required by package `redacted-web v0.1.0`
versions that meet the requirements `^0.16.0` are: 0.16.0

the package `ring` links to the native library `ring-asm`, but it conflicts with a previous package which links to `ring-asm` as well:
package `ring v0.14.6`
    ... which is depended on by `redacted v0.9.0`
    ... which is depended on by `redacted-web v0.1.0`

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

To be clear, cargo update works fine since the dep is specified as ring = "0.14.6".

[kornelski]

I've created a workaround for this — a command that just checks cargo metadata against the index, without trying to be clever about resolving the versions:

https://lib.rs/cargo-upgrades

[jbg]

@kornelski perfect, that does a great job. thanks!