As the title says, it just does nothing.
$ cargo new --bin hello
Created binary (application) `hello` project
$ cd hello/
$ cargo install
Installing hello v0.1.0 (file:///private/tmp/hello)
Compiling hello v0.1.0 (file:///private/tmp/hello)
Finished release [optimized] target(s) in 0.22 secs
Installing /Users/andrea/.cargo/bin/hello
$ hello
Hello, world!
$ cargo uninstall
$ hello # still present
Hello, world!
$ which hello
/Users/andrea/.cargo/bin/hello
Is this the intended behaviour?
On macOS:
$ cargo --version
cargo 1.26.0 (0e7c5a931 2018-04-06)
Oh dear I believe this is bug! I think we probably want to make this an error as ideally we'd like to deprecate a bare cargo install as well
ideally we'd like to deprecate a bare cargo install as well
What would be the alternative then?
For installation it'd be cargo install --path . and probably cargo uninstall --path .
What's wrong with making --path default to .?
Also a possibility!
Looks like this was fixed. Doing cargo install errors out.
error: Using `cargo install` to install the binaries for the package in current working directory is no longer supported, use `cargo install --path .` instead. Use `cargo build` if you want to simply build the package.
Yeah, that was done. And looks like the uninstall part works as expected now:
17:57:06 $ cargo uninstall
Removing /Users/dnw/.cargo/bin/hello
Most helpful comment
What's wrong with making
--pathdefault to.?