[RFC] `cargo install` should ignore the default build target

[japaric]

This is a papercut embedded users often encounter as our templates ship with a .cargo/config file
that sets a default build target:

$ cargo new --lib foo && cd $_

$ mkdir .cargo
$ cat >.cargo/config <<'EOF'
[build]
target = "thumbv7em-none-eabi"
EOF

$ cargo install cargo-binutils
    Updating registry `https://github.com/rust-lang/crates.io-index`
  Installing cargo-binutils v0.1.1
   Compiling unicode-xid v0.1.0
   Compiling failure_derive v0.1.2
   Compiling serde v1.0.70
   Compiling libc v0.2.42
   Compiling void v1.0.2
   Compiling semver-parser v0.7.0
   Compiling rustc-demangle v0.1.9
   Compiling ucd-util v0.1.1
error[E0463]: can't find crate for `std`
  |
  = note: the `thumbv7em-none-eabi` target may not be installed

The issue is that cargo-install compiles cargo-binutils for the thumbv7em-none-eabi target
and that fails because there's no pre-compiled std for that target. Even if the compilation
did succeed that would result in an ARM binary being installed and a x86_64 host would not be able
to run it in most cases.

I propose that cargo-install ignores the default build target if one is set in a Cargo
configuration file. In the, IMO, rare case where one does want to install a cross compiled binary
cargo install --target $T would be the way to go.

This is technically a breaking change but I doubt anyone is relying on this.

Thoughts?

cc @alexcrichton

[alexcrichton]

This was originally asked for in #5441 and implemented in #5606, but it was reverted in #5614 to be more consistent with Cargo with --target being supported

It's perhaps not a bad idea though to specifically only recognize --target (and maybe env vars) but otherwise ignore [build] target!

[japaric]

@alexcrichton Interesting!

The case I'm describing is about installing a general purpose tool like ripgrep or racer. In my mind, by typing cargo install I really mean "install this for the host because I want this in my PATH" so I don't think it should matter from where I invoke the command: I could be invoking the command from a Cargo project (because I happen to be there atm) or from home or from somewhere else.

So, IMO, either cargo install (without --target) should ignore both .cargo/config and env vars, OR we should add a --host (or --local) flag to make cargo install compile the binary for the host. The later option seems redundant to me because I only ever use cargo install for local installs.

cc @matklad

[dwijnand]

Could bundle this behaviour change to cargo install with #5327 under edition = "2018".

[alexcrichton]

I think that makes sense to me to ignore env vars and .cargo/config (aka ambient configuration) and only accept --target for cargo install invocations

[traviscross]

Regarding the question of whether anyone was relying on this, I was relying on this to set x86_64-unknown-linux-musl as my default target in ~/.cargo/config. The --target option is definitely an improvement, but it doesn't help in changing the default.

While it is surprising that a .cargo/config file in the current directory (or its parents) would affect the behavior of cargo install, it's equally surprising that a value in $HOME/.cargo/config would be ignored.

Perhaps the actually correct behavior is that cargo install should load only $HOME/.cargo/config instead of performing the normal tree walk. This would be a more consistent behavior, and would avoid any other surprises due to current or future .cargo/config values affecting cargo install.

That is, the expected behavior is that no value, not just build.target, from $PWD/.cargo/config (or $PWD/../.cargo/config, etc.) should affect cargo install. But all values from $HOME/.cargo/config should affect cargo install.

[alexcrichton]

@traviscross sorry for the breakage, but that sounds pretty reasonable to me!

@japaric would that solution cause issues for the embedded usage perhaps?

[japaric]

@alexcrichton No, I don't see any trouble. We only use project local .cargo/configs.

[alexcrichton]

Ok great! @traviscross want to open a dedicated issue for this?

[traviscross]

Thanks @alexcrichton, @japaric; sure, it's now opened as #6025.