Adding new cargo commands for adding and removeing package to a project

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 run does install packages from the internet.


Why this type of features are not added to core cargo commands or not interested in this type of surge pills

if feel developers are more forces on rust compilers and internal working

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

Apology for that ... ya i will delete that question

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.

1 Like

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.

Eventually we can teach cargo the difference...