`.cargo/config.toml` causes `cargo info` to only read from registry, not local files

[BatmanAoD]

Problem

This is the inverse of #14810.

Based on the design discussions and documentation of cargo info, it should use local Cargo.toml files when the current directory is a crate or workspace containing the specified crate. (Side-note: I would have expected that spec wouldn't be necessary when inside a single crate; is there a good reason for not making spec optional in that case?)

However, it always seems to use the default registry regardless of what my current directory is. In addition to not showing a local filepath, the behaviors I've observed are:

• If I add a feature locally, that feature is not listed.
• If I try to use cargo info for a crate that is not published or is published in a non-default registry (without providing the --registry argument), the tool prints:

       Updating crates.io index
  error: could not find `<spec>` in registry `https://github.com/rust-lang/crates.io-index`
  

With --offline, the "Updating crates.io index" line is skipped, but I get the same behavior.

Update: this is apparently due to my use of .cargo/config.toml. See below.

Steps

1. Create a local crate.
2. Create .cargo/config.toml that explicitly sets registry.default to crates-io.
3. Run cargo info <name>.

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.89.0 (c24e10642 2025-06-23)
release: 1.89.0
commit-hash: c24e1064277fe51ab72011e2612e556ac56addf7
commit-date: 2025-06-23
host: aarch64-apple-darwin
libgit2: 1.9.0 (sys:0.20.2 vendored)
libcurl: 8.7.1 (sys:0.4.80+curl-8.12.1 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 3.5.0 8 Apr 2025
os: Mac OS 15.7.1 [64-bit]

[epage]

I'm not able to reproduce this. I ran on an unpublished crate and it worked.

$ cargo info wscrate
warning: virtual workspace defaulting to `resolver = "1"` despite one or more workspace members being on edition 2024
which implies `resolver = "3"`
note: to keep the current resolver, specify `workspace.resolver = "1"` in the workspace root's manifest
note: to use the edition 2024 resolver, specify `workspace.resolver = "3"` in the workspace root's manifest
note: for more details see https://doc.rust-lang.org/cargo/reference/resolver.html#resolver-versions
wscrate
version: 0.0.0 (from ./)
license: unknown
rust-version: unknown

I ran on clap and it said it said it ran locally

$ cargo info clap
clap #argument #cli #arg #parser #parse
A simple to use, efficient, and full-featured Command Line Argument Parser
version: 4.5.50 (from ./)
license: MIT OR Apache-2.0
rust-version: 1.74
repository: https://github.com/clap-rs/clap
features:
 +default                  = [std, color, help, usage, error-context, suggestions]
  color                    = [clap_builder/color]
  error-context            = [clap_builder/error-context]
  help                     = [clap_builder/help]
  std                      = [clap_builder/std]
  suggestions              = [clap_builder/suggestions]
  usage                    = [clap_builder/usage]
  cargo                    = [clap_builder/cargo]
  debug                    = [clap_builder/debug, clap_derive?/debug]
  deprecated               = [clap_builder/deprecated, clap_derive?/deprecated]
  derive                   = [dep:clap_derive]
  env                      = [clap_builder/env]
  string                   = [clap_builder/string]
  unicode                  = [clap_builder/unicode]
  unstable-derive-ui-tests = []
  unstable-doc             = [clap_builder/unstable-doc, derive]
  unstable-ext             = [clap_builder/unstable-ext]
  unstable-markdown        = [clap_derive/unstable-markdown]
  unstable-styles          = [clap_builder/unstable-styles]
  unstable-v5              = [clap_builder/unstable-v5, clap_derive?/unstable-v5, deprecated]
  wrap_help                = [clap_builder/wrap_help]

[BatmanAoD]

...actually, yeah, sorry, I am also not able to reproduce this with a new repo. Let me get a working reproduction, and that may be enough to figure out what the issue is.

[epage]

(Side-note: I would have expected that spec wouldn't be necessary when inside a single crate; is there a good reason for not making spec optional in that case?)

This was originally intended for viewing other crates. However, I have ended up running into this myself where I just wanted to run cargo info and for it to use the current one. Would be worth considering.

[BatmanAoD]

Actually, it appears that just adding a .cargo/config.toml is what does it:

[registry]
default = "crates-io"

That shouldn't cause any difference in behavior, I think, because crates-io is already the default registry.

[0xPoe]

I can reproduce it. I will take a look.