Cargo.lock in a workspace lists an arbitrary package as the "[root]"

[mbrubeck]

In a workspace, whether it includes a root crate or only a "virtual" manifest, the [root] section of Cargo.lock always lists the last package (alphabetically, by name) in the workspace. For tools like cargo-outdated that parse Cargo.lock and look for the root package, it would be more useful for this section to contain the actual root package if there is one.

For a workspace with no root package, it might be better to omit the [root] section as unnecessary. If that's not possible, then perhaps it should be the first package in the members array, or something else that the developer can control.

[matklad]

The root in the lock file does not carry any meaning and is there only for back compat. Recent Cargo work fine if there is no root section in the lockfile (this was discussed briefly in #3003).

Looks like cargo-outdated should use cargo metadata command instead of parsing lockfiles?

[alexcrichton]

Ah yeah this is an unfortunate compatibility with old lock files (no longer needed), and I think it may just need to be a bug fix in cargo-outdated

[kardeiz]

Whether this is a bug or not, if it is not "fixed" (according to mbrubeck's suggestion) it would at least be nice if this were better documented somewhere. I was really confused looking at my Cargo.lock where there was a random crate as my root. I just spent 30 minutes double checking http://doc.crates.io/manifest.html and https://doc.rust-lang.org/book/second-edition/ch14-03-cargo-workspaces.html to make sure I hadn't misconfigured anything before I ended up here.

[matklad]

@kardeiz I think we can just remove [root] now, filed #4563

[kardeiz]

Okay, that's great! Thanks for the response!