Skip to content
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

Please honor $CARGO_HOME/config.toml unconditionally #8870

Closed
d-e-s-o opened this issue Nov 18, 2020 · 2 comments
Closed

Please honor $CARGO_HOME/config.toml unconditionally #8870

d-e-s-o opened this issue Nov 18, 2020 · 2 comments
Labels
C-bug Category: bug

Comments

@d-e-s-o
Copy link
Contributor

d-e-s-o commented Nov 18, 2020

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:

$ pwd
> ~/local/src/rust/foobar
$ cargo publish --registry my-registry
    Updating `/tmp/my-registry` index
   Packaging foobar v0.1.0 (~/local/src/rust/foobar)
   Verifying foobar v0.1.0 (~/local/src/rust/foobar)
   Compiling foobar v0.1.0
    Finished dev [unoptimized + debuginfo] target(s) in 0.13s
   Uploading foobar v0.1.0 (~/local/src/rust/foobar)

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
@d-e-s-o d-e-s-o added the C-bug Category: bug label Nov 18, 2020
@ehuss
Copy link
Contributor

ehuss commented Nov 23, 2020

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.

@d-e-s-o
Copy link
Contributor Author

d-e-s-o commented Nov 24, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: bug
Projects
None yet
Development

No branches or pull requests

2 participants