Do not deprecate cargo install from current directory

[xlz]

Previous: #5327

The decision was cargo install from current directory is deprecated and will be removed soon.

I find this hard to accept as a new user to Rust. Since Rust is branded as the next big system programming language I would expect it to respect systems conventions, i.e. the deployment holy trinity:

./configure
make
make install

in which make install installs built binaries to appropriate locations so the user can run the binaries without adding ./ prefixes. Now, since Rust has batteries included we can skip ./configure and reasonably expect a build argument in place of make, but why break the expectation of make install?

For a command so central to daily workflows, cargo install --path . makes it suboptimal by allowing a space of ambiguities: is it cargo install ., cargo install --local, cargo install --path=., cargo install --^H^HI still have to check --help?

For the node crowd they can always do cargo uninstall if cargo install is not what they expect, but if I have to look up the documentation just for the equivalent of make install something is wrong here.

[dwijnand]

Forwarding @matklad's TL;DR in #5333 (comment):

The TL;DR here is that we deprecate cargo install in favor of cargo install --path ., because the first form might be wrongly used instead of cargo build, especially if you come from Ruby or JS ecosystems, where bundler install and npm install do completely different things. At the same time, installing the local crate seems to be an extremely niche use-case. So it's better to require slightly more verbose syntax for niche use-case, to be able to provide a targeted warning for common miss use.

I guess you're presenting here that installing local crates isn't such an extremely niche use-case.

Labeled the issue in case we need to discuss it at the next weekly team call meeting (Wednesdays).

[matklad]

Note that cargo install differs significantly from make install: it doesn't install stuff into "appropriate location" (/usr/bin), it installs into ~/.cargo/bin, and it doesn't work with libraries at all. So I guess "cargo install is not equal to X install, please read the docs" applies in this case as well.

[xlz]

make install without sudo installs things into /usr/local/bin, which is not that different from ~/.cargo/bin as they are both modifiable by non-root users and located in $PATH by default.

[t3hmrman]

So I just ran into this while porting a Dockerfile (and was surprised by it, but the error messages from Cargo were extremely helpful as always) -- while I think it's nice to have cargo install still get transformed for cargo install --path . for new users, the comparison to make here is not a good leg to stand on IMO.

make sits above compilers/compilation tools, cargo is a compiler that would be used by make. Projects that want to follow the usual flow (configure + make + make install) should add Makefiles, and hide the fact that cargo is being used at all (some may be using rustc directly).

At present I think this is purely an ergonomics issue, and good arguments could be made either way (preventing misuse vs easier CLI interface).

[nrc]

We discussed this in today's Cargo team meeting. While we understand the motivation for wanting to keep the old behaviour of cargo install, we still believe that the advantages of removing a footgun for some users outweighs the convenience of eliding an argument. Cargo is not very similar to make, and indeed from the classic commands in the OP, make install is the only one that is reflected in Cargo, so we did not feel that it was a very important similarity to keep around.