Optional/preferred checksum when downloading a .crate file; Separate download counts; Download count/cache/delay clarification

[peter-lyons-kehl]

tl;dr:

1. Please clarify crates.io/crates/your-crate-name > "Stats Overview" numbers. It seems either delayed and/or unclear. (More below.)
2. Have https://static.crates.io/crates/{crate}/{crate}-{version}.crate accept an optional/preferred checksum, matching its "checksum" in Cargo.lock of its dependent(s) (if any, or as if it had a dependent - and if it's a binary/dyn library crate, calculating the "checksum" as if it were a standard (static) dependency).
   • potentially report counts of such downloads on crates.io
   • use these counts for adjusting the downloads limit for crate deletions #11901 and Download Count Integrity Issue #13082 and similar.

#1 above:

• Context:
  • tl;dr: Name reservation-only (empty) crate version on crates.io, immediately yanked, still gets 7-11 downloads - but showed only later.
    • In detail: Let's say you have a work-in-progress crate. You already use it locally as a dependency (through path or git), but it's not ready to be published on crates.io. (And maybe you forgot about -alpha and similar semver suffixes.) Because it's being used locally (and referred to in documentation/links that you plan to publish soon), you want to reserve the crate name. So you
      1. open https://crates.io/crates/your-crate-name in a browser (while logged on to crates.io),
      2. cargo publish a simple Cargo.toml and an empty src/lib.rs
      3. immediately (manually) refresh https://crates.io/crates/your-crate-name and yank the version. "Wow, 0 downloads - looks good" - or, so you think...
      4. Come back later (unsure of the minimum period), and there are 7-11 downloads (https://crates.io/crates/impler, https://crates.io/crates/mce - both have only one version ever published each and immediately yanked; they are not name-squatted as there is real work done and they link to their GitHub repos).
      5. Download http://static.crates.io/crates/mce/mce-0.0.1-placeholder-only.crate and check https://crates.io/crates/mce > "Stats Overview" numbers - unchanged!

So, please clarify

• what counts as a displayed download, and
• how often or with what delay are the download counts updated.

#2 above: This (having checksum as an optional parameter for static downloads and counting towards a separate download count) could help to

• exclude/decrease counts from bots/tools that just download crates but don't cargo build etc., and
• prevent downloads of yanked crates (since the bot/tool/user doesn't have the checksum; they could get it from the project's GIT repository, but that can be git push --force overwritten, or the GIT repo can be renamed/deleted and re-created).

[peter-lyons-kehl]

The same with another yanked crate: https://crates.io/crates/dis

• no downloads first:

• half a day later: eight downloads:

[Turbo87]

how often or with what delay are the download counts updated

it's complicated. one of our CDNs only gives us a new log file once per hour, the other every ten minutes. when we process the log files to count the downloads we update the version_downloads table, but the aggregated stats are only calculated a couple of times per day.

[malaire]

Yanking a crate doesn't prevent downloading and yanked crates do get some delayed downloads later on. As one example I maintain a crates mirror which is updated every 1-2 days, so this adds a delayed download for every available crate, including yanked ones.

Also checksums of yanked crates are trivially available to anyone including bots from crates.io-index.

[peter-lyons-kehl]

Thank you. I do know that yanked versions can be downloaded if the local copy already has that version in Cargo.lock. I hoped to prevent such downloads in all other situations, so that we would have more accurate download data.

It seems there's no interest in this.