cargo info reads local crate instead of crates.io when running from the crate directory

[ia0]

Problem

I naively expected that cargo info would always show information from crates.io (as its documentation suggests). However, it seems that cargo info foo-bar would not show information from crates.io if running from the directory of crate foo-bar itself. One has to explicitly pass --registry=crates-io to obtain information from crates.io.

Steps

1. Go to some directory with a Cargo.toml file.
2. Run cargo info foo-bar (where foo-bar is the package.name value in the Cargo.toml file).

Expected: It will contact crates.io and show information from there.

Actual: It reads and show information from the local crate.

Possible Solution(s)

Either update the documentation to mention that local crate is favored. Or always fetch from crates.io.

Notes

cargo help info shows:

NAME
       cargo-info — Display information about a package in the registry. Default registry is crates.io

DESCRIPTION
       This command displays information about a package in the registry. It fetches data from the package’s
       Cargo.toml file and presents it in a human-readable format.

It mentions things like package (something published on crates.io) and crates.io. It doesn't say that it will read the local file system.

Version

cargo 1.84.0-nightly (e75214ea4 2024-10-25)
release: 1.84.0-nightly
commit-hash: e75214ea4936d2f2c909a71a1237042cc0e14b07
commit-date: 2024-10-25
host: x86_64-unknown-linux-gnu
libgit2: 1.8.1 (sys:0.19.0 vendored)
libcurl: 8.9.0-DEV (sys:0.4.74+curl-8.9.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Debian n/a (rodete) [64-bit]

[epage]

@Rustin170506 unsure how to word the documentation besides just not saying where its coming from.

[ia0]

Then I'm assuming the intent is to prefer the local crate if it exists. That's already good to know, because then I know I can always specify --registry=crates-io in shell functions that should work regardless of context (like in which directory it runs from), since the semantics of my shell function is to get the info from crates.io.

[epage]

Yes, it was intentional though I don't remember why we chose that behavior.

Another aspect dependent on your local project is what version is shown. It will prefer versions in your lockfile (and maybe also versions compatible with your MSRV?). This is purely meant to be a UX command and tries to give the information that can be assumed to be most helpful for the user.

I can always specify --registry=crates-io in shell functions that should work regardless of context (like in which directory it runs from), since the semantics of my shell function is to get the info from crates.io.

If you are parsing the output, understand that the output is not a stable format intended for programmatic use. We can change pretty much anything about it without it being a breaking change.

[ia0]

Another aspect dependent on your local project is what version is shown. It will prefer versions in your lockfile (and maybe also versions compatible with your MSRV?). This is purely meant to be a UX command and tries to give the information that can be assumed to be most helpful for the user.

Ok, that would be an issue. However, with some quick testing, it seems that using --registry=crates-io will always get the latest (I guess non-prerelease) version from crates.io, which is the behavior I want.

If you are parsing the output, understand that the output is not a stable format intended for programmatic use. We can change pretty much anything about it without it being a breaking change.

Yes, this is fine by me. I checked for a --porcelain flag and didn't find one, so I assumed this can break in the future. My build is hermetic, so I just need to check for breakage when I update my toolchain. Also, I used to use cargo search before cargo info, so that's still an improvement:

-cargo search "$name" | sed -n '1s/^'"$name"' = "\([0-9.]*\)".*$/\1/p'
+cargo info --registry=crates-io -q "$name" | sed -n 's/^version: //p'