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

Report crates.io metrics in cargo info subcommand #14438

Open
Rustin170506 opened this issue Aug 21, 2024 · 0 comments
Open

Report crates.io metrics in cargo info subcommand #14438

Rustin170506 opened this issue Aug 21, 2024 · 0 comments
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-info S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

Comments

@Rustin170506
Copy link
Member

Problem

In the current cargo info subcommand, its information comes from the Cargo.toml manifest.
cargo-info includes a lot of different metrics exposed via the crates.io API (so separate from the Index and Cargo.toml)

Looking at the list, some that might be useful include

recent download count (popularity)
last updated/released (give a feel for how active development is)
authors (who maintain this package)

Proposed Solution

From #14418, we cannot directly call the API from the crates-io crate because every API from it requires the token/auth to make the API call.

A doable solution would be to add some crates.io specific API and only report these metrics when the registry is crates.io.

Another option would be to directly call the get function from the crates-io crate (make it public and allow users to specify the Auth parameter) in the cargo info module and limit all specific things within that module.

Or we shouldn't do it at all, because there is no way to support it for other registries.

Notes

No response

@Rustin170506 Rustin170506 added C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage. labels Aug 21, 2024
@epage epage added Command-info S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted. and removed S-triage Status: This issue is waiting on initial triage. labels Aug 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-info S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Projects
None yet
Development

No branches or pull requests

2 participants