Consider using cargo_metadata instead of cargo crate about cargo-outdated

[kornelski]

It'd be ideal if Cargo exposed its dependency resolution algorithm as a library. Then even the "temp workspace" hack wouldn't be needed — cargo-outdated could read and evaluate data straight from the API.

[Frederick888]

@WiSaGaN rust-lang/cargo#4309

But even if we put this issue aside, since cargo-outdated has used too many cargo functions, e.g. resolving dependencies, updating various sources, querying crates.io registry, etc, etc, it's just too expensive to duplicate all of these.

[Frederick888]

As cargo-outdated is supposed to be merged into cargo ultimately in the future, I don't think this would be an appropriate action to take.

[WiSaGaN]

@Frederick888 any tracking issue for this incorporation?

[matklad]

Note that there's https://github.com/theduke/crates_io_api for querying crates.io API.

So it seems to me that it should not be significantly harder to avoid depending on Cargo? Specifically:

• call cargo-metadata to learn about project structure and dependencies.
• call crates_io_api to figure out about newer major versions
• do a "create temp workspace" trick, but run cargo metadata on the workspace as a subprocess, to simulate cargo update.