`cargo outdated` misses things?

[roy-work]

E.g., in my case, our Cargo.lock file contains:

[[package]]
name = "base64"
version = "0.21.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9ba43ea6f343b788c8764558649e08df62f86c6ef251fdaeb1ffd010a9ae50a2"

Which is out of date: the latest version on crates.io is v0.21.6.

However, cargo outdated doesn't mention it:

» cargo outdated | grep base64
»

In my case, this is a transitive dependency. This seems like it is related to or similar to #105, which did have this comment:

Their original requests were a bit off IMO but the general idea is that if we do list all the "real" latest versions of transitional dependencies, it would be much too verbose and users can literally do nothing to get rid of them (unless the dependencies are also developed by them).

I won't speak to the verbosity half of the comment, but "literally do nothing to get rid of them" — no, in the case that they're semver compat (this is the case here) you can upgrade them with a simple cargo update -p base64@0.21.4¹ command, which in my case emits the following diff:

 [[package]]
 name = "base64"
-version = "0.21.4"
+version = "0.21.6"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "9ba43ea6f343b788c8764558649e08df62f86c6ef251fdaeb1ffd010a9ae50a2"
+checksum = "c79fed4cdb43e993fcdadc7e58a09fd0e3e649c4436fa11da71c9f1f3ee7feb9"

And that's it.

(¹I have some transitive deps to other, semver incompat versions of base64 that require the @ syntax. If you only have a dep against a single version, it's omittable. Simiarly, my diff is also longer, but that's irrelevant.)

[sdroege]

We have a similar case in gst-plugins-rs. For example, net/webrtc depends on reqwest 0.11 but 0.12 is the latest version.

Running cargo outdated --root-deps-only inside that directory, cargo outdated --root-deps-only --manifest-path net/webrtc/Cargo.toml or generally cargo outdated --root-deps-only --workspace does not list it.

[davidhewitt]

Can you share an exact commit which contains an example of the broken behaviour? That would be a great help with reproduction of the bug.

[sdroege]

cargo-outdated 0.16.0 release, and current main of gst-plugins-rs (i.e. 0d8dc1c1566f62e4a726cd6e533268b5782f748f), but any other commit in the last months behaves the same and previous cargo-outdated releases too.

[cohen604]

I have a similar issue
cargo outdated -R saying that everything is up to date even though I know tower is out of date
the version is cargo-outdated-outdated 0.16.0

[wangeguo]

I have a similar issue:

thiserror = "2.0.3" # currently
thiserror = "2.0.9" # new version

cargo-outdated-outdated 0.16.0

[sdroege]

Workaround for now is to use cargo update --verbose as that lists dependencies that are still at an old version, reliably.