Adding new commands like cargo add <package name> cargo remove <package name> to increase the development experience and avoid unwanted movements in text editor like frequent opening and closing of Cargo.toml file
I current situation we wand to open the Cargo.toml and editing the file for adding new package,Instead of frequent opening and closing of cargo.toml file adding new command features like
cargo add <package name>=<version details> : adds a library to use in your cargo.toml and install for the project
cargo remove <package name> : removes an unused library or unwanted from the Cargo.toml file and remove from project also
and one more note : It will be nice if cargo run or cargo build first check the system for the package of the particular version available if not found print error message that the package is not found ,then use internet to install the package using cargo install
Cargo supports integration with external tools, you can install cargo-edit and pretty much get what you’re asking for.
Install it with cargo install cargo-edit.
Keep it up to date using cargo-update (installed by cargo install cargo-update, invoked with cargo install-update -a).
I’m not sure what exactly you’re asking for here. cargo build or rundoes install packages from the internet.
There is precedent for integrating functionality of external tools into cargo itself. I don’t know when and/or why something like this is done. One aspect is probably stability. You’d need to settle on the interface and could never improve it later. Also since cargo already supports integration of external tools, it isn’t really much of a loss to not integrate something.
I don’t think this is an appropriate question to ask. Rust (including cargo) is an open-source project where much (or most(?)) of the work is done by volunteers in their free time. Lazy people wouldn’t be developers of cargo in the first place
There's work in progress to add it to cargo, but this issue has died due to a case of "perfect is the enemy of the good".
The intention was to implement this without changing any other bit of syntax in Cargo.toml (i.e. not sorting fields accidentally, etc.), and this self-imposed additional requirement turned out to be hard to implement, and is taking years now.
Hmm. Usually when I add a dependency I delve into Cargo.toml specifically to ensure the dependency list stays alphabetized. Makes it much easier to find anything later.
I also keep mine alphabetized, but in two sections: public and private dependencies, so an overall sorting would make that harder. Though keeping track of what is actually public and private is hard, so I suspect that my Cargo.toml is not actually accurate most of the time.