-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement cargo install
#2026
Implement cargo install
#2026
Conversation
r? @wycats (rust_highfive has picked a reviewer for you, use r? to override) |
the installation root's `bin` folder. The installation root is determined, in | ||
order of precedence, by `--root`, `$CARGO_INSTALL_ROOT`, the `install.root` | ||
configuration key, and finally the home directory (which is either | ||
`$CARGO_HOME` if set or `$HOME/.cargo` by default). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't inventing a new one, as ~/.cargo
is already being used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's why it's continuing discomfort 😛
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. |
Can we amend the RFC afterwards, so there's consistency? |
@florianjacob that's covered by #1734 |
@steveklabnik #1734 only covers the xdg basedir specification regarding where to put cargo's regular config and data files. But |
@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... :/ |
53adb87
to
7abffd8
Compare
@bors r+ |
📌 Commit 7abffd8 has been approved by |
⌛ Testing commit 7abffd8 with merge d090d38... |
💔 Test failed - cargo-mac-64 |
This commit is an implementation of [RFC 1200][rfc] 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). [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1200-cargo-install.md
7abffd8
to
bc60f64
Compare
@bors: r=brson |
📌 Commit bc60f64 has been approved by |
This commit is an implementation of [RFC 1200][rfc] 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). [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1200-cargo-install.md
☀️ 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 |
This way, people don't necessarily have to set `TM_RACER`. Add in the locations that [cargo install](rust-lang/cargo#2026) will be using, on the assumption that racer will likely start recommending cargo install soon.
This commit is an implementation of RFC 1200 which brings two new
subcommands:
cargo install
andcargo uninstall
. Most of this is a straightimplementation of the RFC, but a few tweaks were made:
-p
or--package
arguments are no longer needed as you just passcrate
as a bare argument to the command, this meanscargo install foo
works and downloads from crates.io by default.
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).