Add cargo doctor

[Zerotask]

Describe the problem you are trying to solve

Rust consists of many tools and at the moment there is no single command to check if everything is fine and up to date.

Describe the solution you'd like

Similar to npm's doctor command there could be a cargo doctor command which checks the whole ecosystem if everything is working as expected and is up to date.
This checks could include:

• rustc
• cargo
• cargo binaries
• ping crates.io
• configuration / env / paths
• caches etc.

cargo doctor could also give specific solutions, e. g. if rustc is outdated, the recommendation would be:
run rustup update to get the newest version.

Here's an example of npm doctor:

[jhpratt]

This could be implemented as a third-party crate first. There's no reason it needs to be done as part of cargo proper immediately.

[mfdorst]

@jhpratt it could, but if there is something wrong with your cargo then it might be a bit of a chicken and egg problem having to run cargo install cargo-doctor before you can run cargo doctor - what if something is broken which is preventing cargo install from working? Or maybe that's not a thing that really happens, I don't know.

[mfdorst]

Oh, as it turns out cargo-doctor does exist already.

Edit: my bad, that crate is has nothing to do with this.

[jhpratt]

If something is wrong with cargo, how would this proposed command run? I'm also not aware of any issue remotely resembling what you're saying.

My point is only that this is a significant request with no actual implementation to date. On the contrary there are commands such as cargo add that have near-universal acceptance yet are still not part of cargo proper. The bar is very high to get in cargo, and there is zero explanation as to why this shouldn't be done in an external crate like most other commands.

Edit: Just saw the second response. The linked crate has nothing in common whatsoever with this proposal.

[mfdorst]

I agree that this is a significant (and somewhat vague) request and it is better implemented as a standalone crate first, as that seems to be the cargo way. However there there may still be good reasons to have something of this sort shipped with cargo.

If something is wrong with cargo, how would this proposed command run?

You could have moved or deleted or somehow borked your rustc binary, so some cargo operations would still work, but cargo install would tend to fail. Not saying that's likely, just that it is possible. I don't know if that justifies this cargo doctor idea though.

The linked crate has nothing in common whatsoever with this proposal.

Yeah you're right. I read cargo-doctor and just sort of assumed that it would be like brew doctor or npm doctor but it's nothing of the sort.

[jhpratt]

However there there may still be good reasons to have something of this sort shipped with cargo.

Sure, once there's a proof of concept that is widely used. As I've said, there are other crates that have near-unanimous adoption yet aren't part of cargo proper. Given this this doesn't even exist, I see no feasible way this would be added to cargo directly.

I don't know if that justifies this cargo doctor idea though.

I certainly don't think so, especially not immediately.

---

I'll be dropping out of this issue. I've made my point clear, and I strongly oppose any effort to implement this in cargo proper without it first existing as an external crate.

[Zerotask]

This is a proposal, not a "somewhat vague request".

In first instance we should talk and think about the added value this command would give developers and whether this should be a part of the default Cargo toolchain or not.
If the advantage is big enough, then there is no reason for me to go the long way and create a third-party command first. This would people also lead to always just point to this third-party command.

If there are strict requirements it would be more helpful If you would link them instead of downvoting my proposal.
Besides that I don't see a real counterargument from you.

If a decision is made and people agree on it, then we can start talking about the concept / design. No one said that this proposal is ready to create a PR for it.

[mfdorst]

This is a proposal, not a "somewhat vague request".

... There could be [a command] which checks the whole ecosystem if everything is working as expected and is up to date.

This is vague. What do you mean by "the whole ecosystem" specifically? What kind of checks should it perform to determine if things are "working as expected"?

[Zerotask]

I wrote that in my first post, I also mentioned npm doctor as a reference. So what exactly is vague for you? Your post is somewhat vague.

How each check is done, are design / implementation details.
But there is no need right now to discuss about that. In first instance we should think about the benefit, as I already said.

[kornelski]

This would be very useful. On macOS there's a brew doctor, and it's incredibly helpful for troubleshooting.

In user forums people often come with questions about their damaged/incomplete/misconfigured Rust installations (e.g. lacking Visual Studio linker, using 64-bit Rust with 32-bit MinGW, Intel Rust or ARM Mac, having distro-provided Rust/Cargo package that doesn't see rustup-provided toolchains, etc.)

I think this functionality would be best in rustup, since users may have defunct Rust/Cargo installation, so they may be unable to even run cargo doctor, and even less likely to be able to successfully run cargo install cargo-doctor. Once rustup confirms cargo is installed properly, it could delegate cargo-specific checks to cargo doctor.