`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'

[0xPoe]

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

0xPoe/cargo-information#60

[0xPoe]

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

How about this?

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

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

[ia0]

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

Rustin170506/cargo-information#60

Thanks for the link! But this doesn't really contain a rationale for the current behavior though. Even 0xPoe/cargo-information#66 doesn't. It seems the history was (AFAICT):

• cargo info used to panic on local crates.
• Someone suggested a --local flag (would have been nice, such that behavior is uniform and unsurprising).
• The panic was changed into an error in fix: bail out an error for non remote registry  0xPoe/cargo-information#64 (all right).
• The error was ignored in feat: allow inspect local workspace packages 0xPoe/cargo-information#66 to show the local crate.

The closest thing I found to a rationale is 0xPoe/cargo-information#66 (comment) but I'm not sure I interpret it correctly (I'm interpreting it as "we don't want to contact crates.io with a crate name if it happens to not have been published yet").

Is it possible to point to the rationale (if my archeology skills are failing) or document it here (otherwise)?

[epage]

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

How about this?

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

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

I think we should probably be more brief in the NAME than that.

Also iirc, we support a PackageIdSpec, the only difference is what a bare <pkgname> does, so the command can show a dependency from anywhere. This is really a matter of defaults for the spec parameter.

[ia0]

Actually, the documentation of spec is correct, so what about simplifying the name and description by removing mentions of the registry?

NAME
       cargo-info — Display information about a package

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

The user would then have to read further the documentation of spec:

OPTIONS
   Info Options
       spec
           Fetch information about the specified package. The spec can be a package ID, see cargo-pkgid(1) for the SPEC format. If the specified package is part of the current workspace, information from the local Cargo.toml
           file will be displayed. If the Cargo.lock file does not exist, it will be created. If no version is specified, the appropriate version will be selected based on the Minimum Supported Rust Version (MSRV).

If we want, we can modify the description to say that what is meant by "the package" is contextual and depends on whether the package is part of the current workspace. But I don't think this is needed.

[epage]

Seems fine with me