Where should `cargo verify-project` go?

[weihanglo]

Problem

I never found cargo verify-project useful. It never checks semantics of Cargo.toml. What it does is merely

• Locating a workspace.
• Parsing Cargo.toml and ensuring that be valid TOML, during the course of locating a workspace.

I don't know if in the wild it is heavily used, but apparently on GitHub it's not (see this search result). It also causes confusions like people expecting it to verify more stuff (#11202).

I wonder if it's time to decide how this command should be.

Proposed Solution

We have at least two choices.

• Make it clear that what cargo verify-project verifies. Perhaps at this moment only TOML syntax. We could expand to simple manifest semantic, though the line will never be clear and can't be a complete verification.

• Mark cargo verify-project as deprecated. Whomever want to use it could continue, though we don't add any support in the future.

  cargo locate-project --workspace might be a good alternative. (Well, not completely. locate-project additionally checks UTF8 for some unknown reason. And IMO it should be allowed.)

Notes

Commit: e8adba9d24257e14fef8793cecabb55b2fbcd0e3

[weihanglo]

This is the oldest commit I found https://github.com/rust-lang/cargo/commit/4de86d2eec82a92944245d0f269fe55907135de7 relevant. Looks like cargo-verify-project ought to be more useful than it is now.

https://github.com/rust-lang/cargo/blob/4de86d2eec82a92944245d0f269fe55907135de7/README.md?plain=1#L32-L39

[epage]

... I wonder if this predates the rename of project to package which would explain why it uses project in the name.

In general, I want to re-examing our plumbing and see if there is a better route to go, inspired by the Argon/smelt ideas.

[ehuss]

The cargo team discussed this, and decided that the verify-project command should probably be deprecated. The command is almost never used, and doesn't really do very much (and probably not what people expect).

In the future, we may consider undeprecating it, replacing it with a different command, or setting it up under a unified plumbing system.

We didn't discuss the exact details of how it should be deprecated (possibly similar to read-manifest?), but I would expect at least marking it in the documentation. We could also start removing it from the documentation or the command listings?

[766974616c79]

I suggest the same as with read-manifest:

• Keep the command in cargo --list.
• Remove it from the documentation
• Notify that the command is deprecated as with cargo help read-manifest

[weihanglo]

Sounds good to me to align with cargo read-manifest as a starting point! Feel free to submit a PR.

[766974616c79]

@rustbot claim