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

The option to use database dumps instead of crates.io API is not apparent #20

Open
jyn514 opened this issue Nov 6, 2020 · 6 comments
Open
Labels
question Further information is requested

Comments

@jyn514
Copy link

jyn514 commented Nov 6, 2020

2 seconds per crate is really long if there are a lot of crates. https://crates.io/data-access

For information through the index, it would be nice to use the index before downloading the dump.

@jyn514
Copy link
Author

jyn514 commented Nov 6, 2020

It turns out that you can do this by opting in with cargo supply-chain update. That is mentioned in the help text for commands that download data:

The `crates.io` cache was not found or it is invalid.
  Run `cargo supply-chain update` to generate it.

Fetching publisher info from crates.io
This will take roughly 2 seconds per crate due to API rate limits

However, it doesn't make it clear that it goes through a different mechanism than the API - I assumed it would try to make an API call for each crate on crates.io and chose not to run it.

@Shnatsel
Copy link
Member

I trust you that the usability issue is real, but I don't see how I can improve on this. This is currently documented in both the help text (see --help), and running the commands themselves also shows a message about it.

Any suggestions?

@Shnatsel Shnatsel added the question Further information is requested label Dec 22, 2020
@Shnatsel Shnatsel changed the title Use database dumps instead of crates.io API The option to use database dumps instead of crates.io API is not apparent Dec 22, 2020
@jyn514
Copy link
Author

jyn514 commented Dec 23, 2020

Well I feel silly now that you said that ... I don't know that there's much to change here, I think I should probably just read --help more carefully.

@Shnatsel
Copy link
Member

It is a well-known fact in UX design that people click through any prompts and warnings, especially on Windows, so the interfaces have evolved to avoid the need for warnings - e.g. providing an option to undo an action instead of asking for confirmation.

The fact that you didn't read --help is valuable real-world data, and indicates that at least some other people will do that. I just need to figure out how to make a UI that communicates better than the current one.

@HeroicKatora
Copy link
Collaborator

Reminds me of: 'In the face of ambiguity, refuse the temptation to guess.'. Maybe it could default to refusing to do anything unless specifically advised to query the data from the API by an extra command line option.

@AliSajid
Copy link

To add to this discussion, I think adding a separate, prominent section in the README will definitely help. It could potentially be titled "Offline Access" or "Speeding up Data Access"?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants