Merge cargo-rm into cargo

[epage]

A scratchpad like #568

Ordered list:

• Update CLI flags to match the merged cargo-add
• Add --target support (Add --target flag to cargo-rm #711)
• Dry-run support
• First letter of warnings/errors should be lower case
• Change CRATE in help to DEP to clarify that we want the dependency name and not the crate name (in case of a rename)
• Create merge-rm branch
• Refactor to match cargo's directory structure
• Port tests to snapbox (like refactor(tests): Reduce reliance on CARGO_IS_TEST #659)
• Port tests to cargo-test-support
• Refactor out of cargos ops/cargo_add/manifest.rs into a place for reuse
  • Possibilities: ops/cargo_edit or edit and make it public
• Port to cargo's internals
• Merge the command (like in feat: Import cargo-add into cargo rust-lang/cargo#10472)
• Update documentation (like in Document cargo-add rust-lang/cargo#10578)
• Update completions (like in Completion support for cargo-add rust-lang/cargo#10577)

[epage]

Currently:

cargo-rm 0.9.0
Remove a dependency from a Cargo.toml manifest file

USAGE:
    cargo rm [OPTIONS] <CRATE>...

ARGS:
    <CRATE>...    Crates to be removed

OPTIONS:
    -B, --build                   Remove crate as build dependency
    -D, --dev                     Remove crate as development dependency
    -h, --help                    Print help information
        --manifest-path <PATH>    Path to the manifest to remove a dependency from
    -p, --package <PKGID>         Package id of the crate to remove this dependency from
    -q, --quiet                   Do not print any output in case of success
    -V, --version                 Print version information
    -Z <FLAG>                     Unstable (nightly-only) flags

Only operates on one crate

The positional argument is list of dependency keys to remove

Cleans up features when done

[epage]

Out of scope:

• cargo remove should clean up removed dependencies from the cache #647

Too immature

• RFC: cargo rm --unused #415

Move to cargo:

• [feature] cargo rm remove deps with a dash instead of an underscore #690

Fix before merging

• Optionally have set-version update Cargo.lock #698

[epage]

(Python) poetry remove

• Dry run support

(Javascript) yarn remove

• Supports wildcards

(Javascript) pnpm remove

(Go) go get

• go get foo@none to remove

(Julia) pkg rm

(Ruby) bundle remove

(Dart) dart pub remove

[cassaundra]

Hello! Per some conversations with @epage, I will be working on this feature for the time being. I'll start leaving my notes on this issue as well.

[cassaundra]

Expanded list of prior art:

(Python) poetry remove

• Supports dry run

(JavaScript) yarn remove

• Supports wildcards

(JavaScript) pnpm remove

(Go) go get

• go get foo@none to remove

(Julia) pkg rm

• Supports --all to remove all dependencies

(Ruby) bundle remove

(Dart) dart pub remove

• Supports dry run

(Lua) luarocks remove

• Supports force remove

(.NET) Uninstall-Package

• Supports dry run
• Supports removal of dependencies
• Supports force remove (disregards dependencies)

(Haxe) haxelib remove

(Racket) raco pkg remove

• Supports dry run
• Supports force remove (disregards dependencies)
• Supports demotion to weak dependency (sort of a corollary of force remove)

[epage]

Happen to know what distinguishes a force-remove from a remove?

I'm also a bit baffled as to why some tools provide an --all. Seems unlikely someone will go nuclear with their dependencies like that.

[cassaundra]

Happen to know what distinguishes a force-remove from a remove?

If another dependency depends on the package to be removed, it seems the default behavior in these programs would be to raise an error. A force remove disregards that error, and removes the package anyway.

I'm pretty confident this behavior wouldn't exist in Cargo, since removing a dependended-upon crate from the manifest would still keep the dependency in the graph, just not as a top-level dependency. That being said, it would be good to know whether there are any edge cases in which removing a dependency could result in a dependency resolution issue.

I'm also a bit baffled as to why some tools provide an --all. Seems unlikely someone will go nuclear with their dependencies like that.

I thought it was weird too! My intuition here is that it could be useful in some sort of interactive environment, like a REPL. Looking at the original PR for --all in Julia (JuliaLang/Pkg.jl#2432), it seems the flag was added to several other subcommands at the same time, so it's probably just a fun artifact that arose out of that.

[epage]

That being said, it would be good to know whether there are any edge cases in which removing a dependency could result in a dependency resolution issue.

Right now, we always remove even if it is a known breaking change. I wonder if we the following cases should require force-remove

• Removing an optional dependency that is exposed as a feature
• Removing a public dependency (RFC only at this time, its not implemented)

[cassaundra]

Removing an optional dependency that is exposed as a feature

That makes sense to me.

Removing a public dependency (RFC only at this time, its not implemented)

Good to know. I suppose if any progress is made on that front, we could revisit this?

[epage]

Good to know. I suppose if any progress is made on that front, we could revisit this?

I'm assuming cargo remove will be merged first, so we'd just make a note on the public dependency tracking issue that this needs to be resolved.

[cassaundra]

Do you think breaking changes should be considered opt-in (with --force) or opt-out (with something like --no-breaking)? Not exactly sure what the user would expect out of this situation.

For that matter, adding a dependency can in some cases result in a breaking change, so I worry that it runs the risk of setting a precedent that we can't actually uphold.

[epage]

Do you think breaking changes should be considered opt-in (with --force) or opt-out (with something like --no-breaking)? Not exactly sure what the user would expect out of this situation.

If we have the feature at all, I feel like it should be --force. Opting in to not break feels a little weird and generally when preventing harm you do it by default. I'm not entirely sold on the feature though. I'd say go implement it or not as you see fit and we'll include it in the proposal to merge the command for discussing.

adding a dependency can in some cases result in a breaking change

How so?