cargo remove should clean up removed dependencies from the cache

[AuracleTech]

After installing cargo-edit I can cargo add crate_name, great But now to remove one, cargo rm doesn't seem to delete the crate and its dependencies Like, there's no logging, there's no progress, did it remove all packages, or just unlinked them?

Also, why cargo add But cargo rm

Why cut the word? Put both option at least, the convention for rust is using the whole word, I don't understand why this one is an exception.

[epage]

But now to remove one, cargo rm doesn't seem to delete the crate and its dependencies

What are you observing that leads you to say this?

I just went into a project with the following lines in Cargo.toml:

[dependencies]
cargo_metadata = "0.14"

I then ran

$ cargo rm cargo_metadata
    Removing cargo_metadata from dependencies

and now my Cargo.toml file does not list it.

Why cut the word? Put both option at least, the convention for rust is using the whole word, I don't understand why this one is an exception.

I'm not aware of any such convention. Rust regularly uses abbreviations (Buf, str, etc). Rust has also preferred un-rust-like naming conventions when there is strong enough precedence in other ecosystems (can't remember which function but there is some integer or float functions that have no _ in them between words).

However, it seems the precedence among related tools is to use remove despite the unix utility rms precedence (after surveying all other commands that have an add).

This is s topic we'll review when we are working on merging cargo-rm into cargo. Right now, the focus is on cargo-add.

[AuracleTech]

and now my Cargo.toml file does not list it.

What I meant is the dependencies might not be on the cargo.toml anymore, but they're still downloaded. Node.js as example deletes the packages and their dependencies from the disk, liberating space.

However, it seems the precedence among related tools is to use remove despite the unix utility rms precedence (after surveying all other commands that have an add).

Happy to hear we might be able to use cargo remove eventually! 😄

[epage]

What I meant is the dependencies might not be on the cargo.toml anymore, but they're still downloaded. Node.js as example deletes the packages and their dependencies from the disk, liberating space.

The cases for clean up I can think of

• The downloaded crate: this is global for the user, so we don't have a way to garbage collect this
• Crate-specific intermediate build artifacts: this is global to workspace and we'd to check if that dependency is no longer in the lock file. Overall, I see this as a low priority nice to have since removing dependencies is usually not a common workflow for space savings.
• Vendored dependencies (ie copied into the git repo): we've not really explored how these tools should interact with cargo vendor though this one makes sense to do.

[epage]

Forgot to add, of those, what are your expectations and care abouts?