Implement `cargo install`

[alexcrichton]

This commit is an implementation of RFC 1200 which brings two new
subcommands: cargo install and cargo uninstall. Most of this is a straight
implementation of the RFC, but a few tweaks were made:

• The -p or --package arguments are no longer needed as you just pass
  crate as a bare argument to the command, this means cargo install foo
  works and downloads from crates.io by default.
• Some logic around selecting which crate in a multi-crate repo is installed has
  been tweaked slightly, but mostly in the realm of "let's do the thing that
  makes sense" rather than the literal "let's do what's in the RFC".
  Specifically, we don't pick a crate with examples if there are multiple crates
  with binaries (instead an error is generated saying there are multiple binary
  crates).

[rust-highfive]

r? @wycats

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

r? @wycats + @brson

[eternaleye]

I'd like to note my continuing discomfort with inventing Yet Another Language-Specific Homedir Install Location, rather than using ${HOME}/.local/, which is intended for user-scoped installation.

[steveklabnik]

This isn't inventing a new one, as ~/.cargo is already being used.

[eternaleye]

That's why it's continuing discomfort 😛

[eternaleye]

If I'm reading this correctly, this has one metadata file per install destination, listing all crates installed there (with their inner metadata)?

If so, this is exactly the kind of design I mentioned as being actively hostile to system package managers, as crate installs now mutate a single shared state, rather than being separable by way of (say) installing individual drop-in files to a directory. I really dislike this, as it forms an ABI which (even if not public) will be a pain to change later - and if not changed, makes interop with system PMs needlessly difficult and fraught.

By having a central state, a naive implementation simply appends new installs to the state file. If that is done, then installing crates which are independent of each other is not commutative - this breaks PMs.

A less naive implementation sorts the state file - in this case, it is commutative, but the PM needs to be specially aware of the state file, and may even need to manually regenerate it from its own metadata. This is more work for distro packagers, and weakens guarantees (such as checksums) that the PM can provide.

A much friendlier implementation would have a central directory, and drop a metadata file in per-crate. With that, all files installed by a crate can be presumed immutable by the system PM, which is far, FAR friendlier.

(A package manager's dream would be for the installed files of every package to be non-colliding and immutable, in which case all of us packagers could go home and sleep. Rust, interestingly enough, comes closer to this than just about anything else with its config hashes on libraries and such.)

[alexcrichton]

Note that looking at this from a package manager perspective isn't necessarily this intention, this is intended to be purely Cargo-only metadata. It's not the intention for cargo install to install binaries into system directories (like /usr/local) by default. In that sense I expect any package manager to simply ignore or delete this file or not even use cargo install at all when preparing a package.

It was discussed having a flag to not generate this when a package is installed on the RFC as well.

[eternaleye]

My concerns lie along the following lines:
1.) cargo install is a general enough tool to tempt people to apply it to system-wide use (i.e., it supports arbitrary destinations via --root and such). People already do this with NPM, gem, etc, and it's really a painful issue.
2.) The metadata is sufficiently useful that there is an incentive for others to parse it
3.) The metadata as specified is unnecessarily hostile to system PMs (i.e., doing it this way doesn't seem to provide much in the way of benefit over ways that would be less hostile)
4.) Simply not installing it at all for the system PM is a potential hazard due to (2) (as well as Cargo itself if --root is passed)

Those make it such that once the problematic way is used, it's going to be very difficult to use a way that is not.

As for a (simple!) solution that's far less problematic, simply having each crate's metadata go in ${ROOT}/some_dir/${CRATE_HASH}.crate.toml would do the trick - it'd be a very limited amount of added complexity (iterate the directory, merge the parsed data) in exchange for something that won't need a redesign later.

(Personally, I'd suggest some_dir be lib/cargo, by analogy with pkgconfig.)

[florianjacob]

I'd also love to see cargo following the xdg basedir specification and the systemd file hierarchy, which, as I just learned, even has a section specifically on where to place user packages like in this case.

[steveklabnik]

"let's do the thing that makes sense" rather than the literal "let's do what's in the RFC".

Can we amend the RFC afterwards, so there's consistency?

[steveklabnik]

@florianjacob that's covered by #1734

[florianjacob]

@steveklabnik #1734 only covers the xdg basedir specification regarding where to put cargo's regular config and data files. But cargo install makes the systemd file hierarchy standard relevant, too, as it specifies how user packages should be put in ~/.local/bin, ~/.local/lib/<arch-id>, ~/.local/lib/<package>/ etc.

[steveklabnik]

@florianjacob regardless, it's off-topic here, as we have an RFC with this design already agreed upon. I'm not saying such a change isn't worth it, but it should be a new issue with its own discussion and everything else.

Though I guess @alexcrichton is already deviating from the RFC... :/

[brson]

@bors r+

[bors]

📌 Commit 7abffd8 has been approved by brson

[bors]

⌛️ Testing commit 7abffd8 with merge d090d38...

[bors]

💔 Test failed - cargo-mac-64

[alexcrichton]

@bors: r=brson

[bors]

📌 Commit bc60f64 has been approved by brson

[bors]

⌛️ Testing commit bc60f64 with merge 1206e5e...

[bors]

☀️ Test successful - cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-gnu-32, cargo-win-gnu-64, cargo-win-msvc-32, cargo-win-msvc-64