`cargo install` ignores local source replacement

[cuviper]

Problem
Since #6026, cargo install only loads configuration from ~/.cargo/config. However, the workflow for tools like cargo-vendor is to create .cargo/config in the current directory for source replacement. We do this for Fedora packaging too. Now that local config is ignored, so install tries to use crates.io again (which fails in Fedora offline builds).

Steps
(in a crate dir that uses some crates.io dependencies)

1. mkdir .cargo
2. cargo vendor > .cargo/config
3. cargo install --path . --verbose
   • See that it is building deps from crates.io, not ./vendor/.

Possible Solution(s)

As a workaround, env CARGO_HOME=$PWD/.cargo cargo install ... seems to work.

Longer term, maybe we need to scale back #6026 to more tightly address the problems it was trying to address (#6025, #5850), but I don't know the best policy for which configs to use.

Notes

Output of cargo version:

cargo 1.31.0 (339d9f9c8 2018-11-16)
release: 1.31.0
commit-hash: 339d9f9c8f400010df3282ae5582bf3a0f739004
commit-date: 2018-11-16

[cuviper]

On discord #cargo, @joshtriplett suggested that cargo should never look at $PWD for configs, but instead look at the crate root only. This makes a lot sense to me. However, it would break any workflows that try to do "remote" builds (--manifest-path) with different local configs.

[joshtriplett]

@cuviper Those workflows should explicitly set $CARGO_HOME.

(That said, we should absolutely detect a cargo configuration in $PWD that we would have read and warn about it, and have a nice long transition.)