You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The cargo reference has the following to say about config.toml:
Cargo allows local configuration for a particular package as well as global configuration. It looks for configuration files in the current directory and all parent directories. If, for example, Cargo were invoked in /projects/foo/bar/baz, then the following configuration files would be probed for and unified in this order:
/projects/foo/bar/baz/.cargo/config.toml
/projects/foo/bar/.cargo/config.toml
/projects/foo/.cargo/config.toml
/projects/.cargo/config.toml
/.cargo/config.toml
$CARGO_HOME/config.toml which defaults to:
Windows: %USERPROFILE%.cargo\config.toml
Unix: $HOME/.cargo/config.toml
With this structure, you can specify configuration per-package, and even possibly check it into version control. You can also specify personal defaults with a configuration file in your home directory.
If a key is specified in multiple config files, the values will get merged together. Numbers, strings, and booleans will use the value in the deeper config directory taking precedence over ancestor directories, where the home directory is the lowest priority. Arrays will be joined together.
So my (arguably wishful) reading of this is that $CARGO_HOME/config.toml is always sourced (the "global" aspect; for the current user I mean, not system-wide). But that does not seem to be the case.
Problem
I have a custom registry in my ~/.cargo/config.toml (just to illustrate the point; every other configuration should work equally well):
# For testing only.
[registries.my-registry]
index = "file:///tmp/my-registry"token = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
If I create a crate below my home directory the registry is known just fine:
If I do the same thing in a project in /tmp, it no longer works:
$ pwd
/tmp/foobar
$ cargo publish --registry my-registry
error: no index found for registry: `my-registry`
Can we please honor the user's home configuration unconditionally? Every sane program does that. I cannot think of a good reason to diverge. This is a source of confusion and it is shocking to see such behavior from cargo.
Notes
$ cargo version
cargo 1.47.0
The text was updated successfully, but these errors were encountered:
Hm, it should always use the config in $CARGO_HOME. Can you check a few things to see why it might not be able to find it? Here are some things to look at:
Is the CARGO_HOME environment variable set?
Is the HOME environment variable set? Does it match the location you expect?
Are there any config files in /.cargo/ or /tmp/.cargo/?
Which platform are you on?
Unfortunately Cargo currently doesn't have much debugging support for determining which config files it is loading.
I see what is happening. Yeah, I do have CARGO_HOME set and pointing to /tmp/cargo-home and so that apparently overwrites the usage of $HOME/.cargo/config.toml. So previously the latter config file was not picked up through CARGO_HOME but just through the hierarchical look up. So in some way the behavior makes sense (and is in line with what the documentation states). I guess that's by design and not going to change then. Sigh.
The
cargo
reference has the following to say aboutconfig.toml
:So my (arguably wishful) reading of this is that
$CARGO_HOME/config.toml
is always sourced (the "global" aspect; for the current user I mean, not system-wide). But that does not seem to be the case.Problem
I have a custom registry in my
~/.cargo/config.toml
(just to illustrate the point; every other configuration should work equally well):If I create a crate below my home directory the registry is known just fine:
If I do the same thing in a project in
/tmp
, it no longer works:Can we please honor the user's home configuration unconditionally? Every sane program does that. I cannot think of a good reason to diverge. This is a source of confusion and it is shocking to see such behavior from
cargo
.Notes
The text was updated successfully, but these errors were encountered: