Open tyranron opened 5 years ago
@lukaslueg Docker images has no zsh
, however. Win users, generally, too.
I suppose the tricky part here is that by changing CARGO_HOME
you change what configuration files cargo reads (it'll now have to read $CARGO_HOME2/.cargo/config
). Imagine something like the following:
# ~/.cargo/config
home = "/path/to/a"
[build]
target = "foo"
Now imagine you invoke cargo
from the directory b
without CARGO_HOME
set. What should the target directory be? ~/.cargo/config
says that it should be "foo"
, but it also says that CARGO_HOME
should have a different value. And if it had that different value, then ~/.cargo/config
would never have been read, which means that the target was never set. It's a little contrived, but suggests there are some weird corner-cases here.
One way to get around this is to have cargo home no be set in the normal configuration files, but instead with a different file under .cargo
. For example, imagine a .cargo/home
which should hold the path that CARGO_HOME
should be set to. cargo
should first check CARGO_HOME
, and use that if set. If not set, it should search up the tree for .cargo/home
, stopping at the first one it finds and using that as the cargo home. And otherwise, it should use ~/.cargo
like today. Only after that process has completed should it start reading configuration files. I think that gets around any weird circular definitions or other recursive shenanigans.
I filed a PR that implements the .cargo/home
idea: https://github.com/rust-lang/cargo/pull/9154
In light of https://internals.rust-lang.org/t/pre-rfc-split-cargo-home/19747, I assume what would be wanted is CARGO_CACHE_HOME
. I suspect that is something we could make overrideable in .cargo/config.toml
.
Describe the problem you are trying to solve
Currently, the
$CARGO_HOME
env var may be set to specify the location of cargo "caches" (fetched crates, binaries installed, etc). When we do not want to use the global one, we can override this for local project by providing directly tocargo
commands:While this works OK, it's still not ergonomic enough for certain situations. For example:
I'm developing HTTP daemon and using Docker. I want
$CARGO_HOME
being reused both for normal builds in terminal or IDE (viacargo build
) and for those ones insideDockerfile
. This makes me:CARGO_HOME=.cache/cargo
for every command (not very handy);export CARGO_HOME=.cache/cargo
each time I'm opening terminal for this project (as I cannot set it globally);docker build
.The problem with
docker build
that I cannot pass arbitrary directory to the build context, only those dirs which are inside cwd. So, I should persist$CARGO_HOME
inside my project root and do it only when using this project specifically. I want no bothering and just runcargo build
ordocker build
without any crates refetches.Describe the solution you'd like
Simply allow to override the
$CARGO_HOME
for the current directory with some sort of configuration file: either.cargo/config
, orCargo.toml
. It will allow to declare the desired value once and just don't bother, while playing well with bothcargo build
/docker build
experiences at the same time.The feature is not new and already exists in package managers for other languages. For example, I can specify the packages cache folder in:
.yarnrc
/.npmrc
file for Yarn/NPM;composer.json
for Composer.