You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
TL;DR: run cargo supply-chain update implicitly from other commands, instead of defaulting to querying the API.
If the cache is expired or nonexistent, and --cache-max-age allows it, we could download the latest DB dump by default instead of fetching live results. This would be a lot faster in the typical case.
We would still need to fall back to querying live data from the API if the latest DB dump published by crates.io is older than --cache-max-age.
The text was updated successfully, but these errors were encountered:
The database dumps are not officially in a stable format, so I could see the format changing in the future and the tool breaking. However, in practice the parts we care about have not changed in years.
The database download also relies on a somewhat fragile order of the files in the archive to reduce the download size. This could easily change without warning and increase the download size considerably.
Finally, these aren't really live results (up to 48 hours out of date by default), but that is probably fine as long as we display a warning about it.
I don't foresee any issues within the code of cargo supply-chain itself.
TL;DR: run
cargo supply-chain update
implicitly from other commands, instead of defaulting to querying the API.If the cache is expired or nonexistent, and
--cache-max-age
allows it, we could download the latest DB dump by default instead of fetching live results. This would be a lot faster in the typical case.We would still need to fall back to querying live data from the API if the latest DB dump published by crates.io is older than
--cache-max-age
.The text was updated successfully, but these errors were encountered: