Moving cargo-edit into cargo has been a slow but fruitful process. Besides any of the technical work involved in getting this into cargo (e.g. making `toml_edi

Moving cargo-edit into cargo has been a slow but fruitful process. Besides any of the technical work involved in getting this into cargo (e.g. making `toml_edit` production-ready), we had a long discussion about the exact UX (https://internals.rust-lang.org/t/feedback-on-cargo-add-before-its-merged/16024 https://internals.rust-lang.org/t/feedback-on-cargo-add-befo...) even after its been sitting in `cargo-edit` for years. `cargo-set-version` has a less clear path to being merged as there isn't as much visible demand for it (there isn't even a `cargo` issue for it). `cargo upgrade` has the problem of trying to solve too many people's needs and is stuck in UX discussion limbo (https://internals.rust-lang.org/t/feedback-on-cargo-upgrade-to-prepare-it-for-merging/17101 https://internals.rust-lang.org/t/feedback-on-cargo-upgrade-...). I'm starting to formulate thoughts on which compromise I want to make to allow that to move forward again. In addition to the plugins you mentioned, some more worth calling out: - cargo-release - cargo-deny - cargo-semver-checks - cargo-hack - cargo-expand - cargo-nextest You can also see - All the plugins at https://crates.io/categories/development-tools::cargo-plugins https://crates.io/categories/development-tools::cargo-plugin... - What people have proposed be added: https://github.com/rust-lang/cargo/issues?q=is%3Aopen+is%3Aissue+label%3AA-new-subcommand https://github.com/rust-lang/cargo/issues?q=is%3Aopen+is%3Ai...