# Cargo sparse protocol feedback thread **URL:** \ **Category:** cargo\ **Created:** [January 30, 2023, 3:07pm UTC](https://internals.rust-lang.org/t/cargo-sparse-protocol-feedback-thread/18234 "2023-01-30T15:07:21Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![ehuss](https://avatars.discourse-cdn.com/v4/letter/e/9de0a6/32.png) [@ehuss](https://internals.rust-lang.org/u/ehuss)\ **Post date:** [January 30, 2023, 3:07pm UTC](https://internals.rust-lang.org/t/cargo-sparse-protocol-feedback-thread/18234/1 "2023-01-30T15:07:22Z")
Cargo's new index protocol will be available starting in Rust 1.68, which will be released on 2023-03-09. This new "sparse" protocol should usually provide a significant performance improvement when accessing [crates.io](http://crates.io). We would like your help in testing this new feature and infrastructure. If you use beta (1.68) or nightly-2023-01-21 or newer, set the environment variable `CARGO_REGISTRIES_CRATES_IO_PROTOCOL=sparse`, or edit your [`.cargo/config.toml` file](https://doc.rust-lang.org/cargo/reference/config.html) to add: ```plaintext [registries.crates-io] protocol = "sparse" ``` We would like to hear reports on your experience. If you run into a problem, please [open an issue](https://github.com/rust-lang/cargo/issues/new?assignees=&labels=C-bug&template=bug_report.yml). If you would like to post general feedback, please leave a comment on this thread. Along with fetching crates and running `cargo update`, we'd also like to hear if you have any issues when running `cargo publish`. Another data point that may be helpful is to gauge how many users are behind a restrictive firewall, proxy, or other network environment that prevents access to the index. More information is available in this blog post: [Help test Cargo's new index protocol | Inside Rust Blog](https://blog.rust-lang.org/inside-rust/2023/01/30/cargo-sparse-protocol.html) ---
**Author:** ![nhoyle](https://avatars.discourse-cdn.com/v4/letter/n/94ad74/32.png) [@nhoyle](https://internals.rust-lang.org/u/nhoyle)\ **Post date:** [January 31, 2023, 5:35pm UTC](https://internals.rust-lang.org/t/cargo-sparse-protocol-feedback-thread/18234/2 "2023-01-31T17:35:19Z")
In limited testing so far, on FreeBSD 13.1, seems to work fine, and quickly. ---
**Author:** ![alexcrichton](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/alexcrichton/32/4501_2.png) [@alexcrichton](https://internals.rust-lang.org/u/alexcrichton)\ **Post date:** [February 1, 2023, 5:16pm UTC](https://internals.rust-lang.org/t/cargo-sparse-protocol-feedback-thread/18234/3 "2023-02-01T17:16:43Z")
The sparse option for fetching has been working like a charm, as expected! For publishing I just now published a workspace of crates with the sparse protocol enabled, and two things I noticed during the publish process was: - Two crates ended up timing out around ~100 "complete" being listed. I haven't previously seen a timeout with the git-based publishing process yet so I'm not sure if this was expected or not. I published ~20 crates with this script and only two timed out, however. I haven't published a ton of crates with the git-based protocol where Cargo waits for the version to be in the index before finishing the `publish` command, but the sparse-version did feel a bit slower than the git-based version. (not that this was head-to-head mind you, just based on previous workspace publications) - Personally I found the "Waiting ..." UI to be sort of confusing. There's a "Fetch ..." progress bar but it's not clear to me what progress is being made as it always jumps to the right quickly. The "complete" counter additionally increments by 2-at-a-time, and the "pending" counter sticks at 1. I originally thought that this was doing recursive resolution since the UI looked the same as during a normal `cargo fetch`, but I suspect it's doing repeated http requests to find the latest version after watching it more. The publication process nonetheless worked without flaw. Thanks again to everyone who's worked on this feature! ---
**Author:** ![ehuss](https://avatars.discourse-cdn.com/v4/letter/e/9de0a6/32.png) [@ehuss](https://internals.rust-lang.org/u/ehuss)\ **Post date:** [February 1, 2023, 10:15pm UTC](https://internals.rust-lang.org/t/cargo-sparse-protocol-feedback-thread/18234/4 "2023-02-01T22:15:52Z")
Thanks for the feedback @alexcrichton! Regarding the delays, there are a few issues there. One is that it relies on invalidating the CDN cache, which can be a little slow with our current provider. One possibility is using a different service which you may be familiar with. Another issue is that [crates.io](http://crates.io) is currently processing requests to update the index one at a time. A potential improvement would be to batch them. A much longer-term solution is to have a different index format that does not require cache invalidation, which is tracked in [Sparse registry indexes should be viewable atomically · Issue #10928 · rust-lang/cargo · GitHub](https://github.com/rust-lang/cargo/issues/10928). Another much longer-term solution is to have a different publishing API and workflow that would allow publishing multiple packages atomically. We may likely need to increase the timeout for when Cargo gives up waiting for the update to appear. The default is currently 60 seconds. There is also a `-Z publish-timeout` option to change that, though that is not necessarily tracked to be something we intend to stabilize. For the UI, yea it is just repeatedly trying to update the index. Ideally I think it should just be a single progress bar. That is tracked in [Extra "Updating index" messages after publishing a crate · Issue #11304 · rust-lang/cargo · GitHub](https://github.com/rust-lang/cargo/issues/11304) and I would love for someone to work on that. ---
**Author:** ![alexcrichton](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/alexcrichton/32/4501_2.png) [@alexcrichton](https://internals.rust-lang.org/u/alexcrichton)\ **Post date:** [February 1, 2023, 10:28pm UTC](https://internals.rust-lang.org/t/cargo-sparse-protocol-feedback-thread/18234/5 "2023-02-01T22:28:34Z")
Sounds like everything I experience is within the realm of "yes, that's expected", so sounds good to me! Nothing is a showstopper by a longshot, and I look forward to Rust 1.68 where I can update CI workflows and such to using sparse by default! ---
**Author:** ![jer](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jer/32/1009_2.png) [@jer](https://internals.rust-lang.org/u/jer)\ **Post date:** [February 2, 2023, 9:23am UTC](https://internals.rust-lang.org/t/cargo-sparse-protocol-feedback-thread/18234/6 "2023-02-02T09:23:40Z")
Added it to the Rust Beta CI tasks for my work project. Seems to consistently save us between 40 and 80s (looks like it saved 30-40s on the registry update, I'm not entirely sure where the other time savings are from, but I'll take it) ---
**Author:** ![noritada](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/noritada/32/9555_2.png) [@noritada](https://internals.rust-lang.org/u/noritada)\ **Post date:** [February 9, 2023, 5:25pm UTC](https://internals.rust-lang.org/t/cargo-sparse-protocol-feedback-thread/18234/7 "2023-02-09T17:25:53Z")
I have used the sparse option to publish a series of packages. It run very lightly and I had no problems. One point I would like to mention is that when I first used it, I was confused by "Waiting" in the last line. Since there was also a word `ctrl-c`, I wasn't sure if the process completed or not. However, I was able to determine that it was over because the "Waiting" was green and the prompt was displayed. It would be a little easier to understand if "Waiting" was in the past tense or the `ctrl-c` message was turned off when the process was finished successfully, wouldn't it? ```rust Compiling pkg v0.0.0 (/path/to/pkg-0.0.0) Finished dev [unoptimized + debuginfo] target(s) in 59.53s Packaged 22 files, 115.4KiB (23.8KiB compressed) Uploading pkg v0.0.0 (/path/to/cwd) Updating crates.io index Waiting on `pkg` to propagate to crates.io index (ctrl-c to wait asynchronously) ``` As a comparison, for example, `cargo install` showed the following in the past tense: ```rust Compiling pkg v0.0.0 (/path/to/cwd) Finished release [optimized] target(s) in 2m 39s Replacing /path/to/bin/exe Replaced package ``` ---
**Author:** ![alexcrichton](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/alexcrichton/32/4501_2.png) [@alexcrichton](https://internals.rust-lang.org/u/alexcrichton)\ **Post date:** [February 13, 2023, 9:20pm UTC](https://internals.rust-lang.org/t/cargo-sparse-protocol-feedback-thread/18234/8 "2023-02-13T21:20:02Z")
> [@alexcrichton](#): > > The "complete" counter additionally increments by 2-at-a-time I was publishing some more crates today for the first time and I noticed that instead of incrementing by 2 the counter was incrementing very rapidly at around 80 per tick. That wasn't necessarily an issue but I was soon rate limited by [crates.io](http://crates.io) with the message: ```rust ... Uploading wit-bindgen-cli v0.3.0 (/home/acrichto/code/wit-bindgen) error: failed to publish to registry at https://crates.io Caused by: the remote server responded with an error (status 429 Too Many Requests): You have published too many crates in a short period of time. Please try again after Mon, 13 Feb 2023 21:21:15 GMT or email help@crates.io to have your limit increased. ``` I'm not sure if these two events were related, however, but wanted to raise the issue since I'm publishing ~8 crates back-to-back and haven't had this come up before. I realize though as I type this that all the crates are new to [crates.io](http://crates.io) whereas many of my publishes historically are for new versions of existing crates, so there may also just be a smaller rate limit for new crates that I'm running into ---
**Author:** ![epage](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/epage/32/3171_2.png) [@epage](https://internals.rust-lang.org/u/epage)\ **Post date:** [February 14, 2023, 2:45am UTC](https://internals.rust-lang.org/t/cargo-sparse-protocol-feedback-thread/18234/9 "2023-02-14T02:45:39Z")
> [@noritada](#): > > One point I would like to mention is that when I first used it, I was confused by "Waiting" in the last line. Since there was also a word `ctrl-c`, I wasn't sure if the process completed or not. The "waiting" message is printed before we block on the server to finish the publish. It is not finished until pretty much at process exit. Hitting `ctrl-c` is an appropriate action to take if you do not care to wait. > [@noritada](#): > > However, I was able to determine that it was over because the "Waiting" was green and the prompt was displayed. I'm a little confused by this. Why would "Waiting" be green affect things? By "prompt was displayed", do you mean the process exited and you saw your command prompt? If so, then yes, the waiting was complete by that point. If it didn't wait very long, then that is great! I sometimes wait several seconds when waiting. ---
**Author:** ![epage](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/epage/32/3171_2.png) [@epage](https://internals.rust-lang.org/u/epage)\ **Post date:** [February 14, 2023, 2:50am UTC](https://internals.rust-lang.org/t/cargo-sparse-protocol-feedback-thread/18234/10 "2023-02-14T02:50:05Z")
I had a `cargo-edit` user report that mixing of the sparse registry (`cargo`) with git registry (`cargo-edit`) wasn't working and got ```rust Error: reference 'refs/heads/master' not found; class=Reference (4); code=NotFound (-3) Caused by: reference 'refs/heads/master' not found; class=Reference (4); code=NotFound (-3) ``` I'm still waiting on a reproduction case but figured I'd give people an early heads up in case something comes of this. We use `crates-index` under the hood and I tried running a thin wrapper around `crates-index` without the `registry` folder and without the index's `.git` folder and neither reproduced the problem. See [`cargo upgrade` fails to get crates version when using sparse registry · Issue #841 · killercup/cargo-edit · GitHub](https://github.com/killercup/cargo-edit/issues/841) ---
**Author:** ![CAD97](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/cad97/32/3460_2.png) [@CAD97](https://internals.rust-lang.org/u/CAD97)\ **Post date:** [February 14, 2023, 7:31am UTC](https://internals.rust-lang.org/t/cargo-sparse-protocol-feedback-thread/18234/11 "2023-02-14T07:31:24Z")
I'm not sure on whose end it is, but running cargo-release in CI gave me a strange error of ```rust error: object not found - no match for id (bc74b69f0a5f9e5286a67f2abad52b85e5c727bb); class=Odb (9) ``` after waiting for confirmation of upload. [run 1](https://github.com/CAD97/simple-interner/actions/runs/4093837108/jobs/7059549923#step:6:29), [run 2](https://github.com/CAD97/simple-interner/actions/runs/4093913851/jobs/7059671552#step:6:36); a local run just after these two CI runs went fine. ---
**Author:** ![epage](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/epage/32/3171_2.png) [@epage](https://internals.rust-lang.org/u/epage)\ **Post date:** [February 14, 2023, 3:06pm UTC](https://internals.rust-lang.org/t/cargo-sparse-protocol-feedback-thread/18234/12 "2023-02-14T15:06:17Z")
For added context, cargo-release is using crates-index as well. ---
**Author:** ![ehuss](https://avatars.discourse-cdn.com/v4/letter/e/9de0a6/32.png) [@ehuss](https://internals.rust-lang.org/u/ehuss)\ **Post date:** [February 14, 2023, 9:22pm UTC](https://internals.rust-lang.org/t/cargo-sparse-protocol-feedback-thread/18234/13 "2023-02-14T21:22:55Z")
I have posted [https://github.com/rust-lang/cargo/pull/11713](https://github.com/rust-lang/cargo/pull/11713) with some tweaks to how the publish status is displayed. It is a bit difficult to succinctly convey the appropriate amount of information, but I gave it a shot. > [@alexcrichton](#): > > I was publishing some more crates today for the first time and I noticed that instead of incrementing by 2 the counter was incrementing very rapidly at around 80 per tick. That wasn't necessarily an issue but I was soon rate limited by [crates.io](http://crates.io) with the message: I don't think the ticking was directly related to your rate limit. The way the progress bar works with the sparse protocol is a little convoluted (there is a global progress bar that doesn't really know how many requests are required). The PR I linked above implements a new progress bar that should tick once per second with a defined limit (60 seconds). There are separate rate limits for publishing new versions versus publishing new crates. I believe the latter is somewhat more restrictive, though I'm not sure what the exact values are. ---
**Author:** ![eggyal](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/eggyal/32/7947_2.png) [@eggyal](https://internals.rust-lang.org/u/eggyal)\ **Post date:** [February 15, 2023, 6:53am UTC](https://internals.rust-lang.org/t/cargo-sparse-protocol-feedback-thread/18234/14 "2023-02-15T06:53:50Z")
Perhaps, before exiting, it would be useful to output a `Finished` message or similar, to avoid any confusion from the last message indicating that work was (then) still pending? ---
**Author:** ![noritada](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/noritada/32/9555_2.png) [@noritada](https://internals.rust-lang.org/u/noritada)\ **Post date:** [February 18, 2023, 5:21am UTC](https://internals.rust-lang.org/t/cargo-sparse-protocol-feedback-thread/18234/15 "2023-02-18T05:21:39Z")
> [@epage](#): > > I'm a little confused by this. Why would "Waiting" be green affect things? By "prompt was displayed", do you mean the process exited and you saw your command prompt? If so, then yes, the waiting was complete by that point. If it didn't wait very long, then that is great! I sometimes wait several seconds when waiting. Yes, I uploaded multiple packages, but in every case I did not wait much longer for the publish to finish successfully and return to the command prompt. Thus, there is nothing wrong with the functionality, I just felt it would be easier to understand if there was a `Finished` message. ---
**Author:** ![noritada](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/noritada/32/9555_2.png) [@noritada](https://internals.rust-lang.org/u/noritada)\ **Post date:** [February 18, 2023, 5:22am UTC](https://internals.rust-lang.org/t/cargo-sparse-protocol-feedback-thread/18234/16 "2023-02-18T05:22:00Z")
> [@eggyal](#): > > Perhaps, before exiting, it would be useful to output a `Finished` message or similar, to avoid any confusion from the last message indicating that work was (then) still pending? Yes, I think so! ---
**Author:** ![josh](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/josh/32/5934_2.png) [@josh](https://internals.rust-lang.org/u/josh)\ **Post date:** [March 16, 2023, 5:48am UTC](https://internals.rust-lang.org/t/cargo-sparse-protocol-feedback-thread/18234/17 "2023-03-16T05:48:02Z")
Just used cargo extensively via a satellite connection on airplane wifi, and the sparse protocol made the difference between usable and usable. I also discovered that several important tools, such as `cargo upgrade` and `cargo deny`, haven't yet been upgraded to support the sparse index. Those tools tried to download the git index, which failed miserably (long delay followed by server-side timeout). ---
**Author:** ![illicitonion](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/illicitonion/32/3886_2.png) [@illicitonion](https://internals.rust-lang.org/u/illicitonion)\ **Post date:** [March 16, 2023, 9:44am UTC](https://internals.rust-lang.org/t/cargo-sparse-protocol-feedback-thread/18234/18 "2023-03-16T09:44:36Z")
We just released sparse index support in [Bazel's crates.io integration](https://bazelbuild.github.io/rules_rust/crate_universe.html) ([Support sparse indexes by illicitonion · Pull Request #1857 · bazelbuild/rules\_rust · GitHub](https://github.com/bazelbuild/rules_rust/pull/1857)) via [crates-index](https://crates.io/crates/crates-index) support (initial support for which was released in [0.19.7](https://crates.io/crates/crates-index/0.19.7)). By default this integration used to do a full index clone when you need to resolve versions, and now it uses sparse index. We are seeing typical version resolution time drop from 2-4 minutes down to \<10 seconds. ---
**Author:** ![dan-fritchman](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/dan-fritchman/32/10701_2.png) [@dan-fritchman](https://internals.rust-lang.org/u/dan-fritchman)\ **Post date:** [March 28, 2023, 6:31pm UTC](https://internals.rust-lang.org/t/cargo-sparse-protocol-feedback-thread/18234/19 "2023-03-28T18:31:30Z")
Love it! Looking forward to seeing this as the default. FWIW my usage is on CentOS, and that works great. ---
**Author:** ![doddi](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/doddi/32/10767_2.png) [@doddi](https://internals.rust-lang.org/u/doddi)\ **Post date:** [April 14, 2023, 3:28pm UTC](https://internals.rust-lang.org/t/cargo-sparse-protocol-feedback-thread/18234/20 "2023-04-14T15:28:48Z")
Apologies if this is the wrong place I have just started to implement a cargo plugin making use of the sparse protocol for a popular repository manager. I have the basics implemented for proxying to [crates.io](http://crates.io) and hosting private crates but I have come across an issue whereby I dont seem to be able to switch entirely across to an alternative registry to [crates.io](http://crates.io) using the sparse protocol. I am finding that I need to explicitly state which dependencies come from that alternative registry, for example: `tokio = { registry = "my-repository" }` Is there a way to switch entirely? Specifying my alternate registry as the default only seem to have an affect for publishing AFAICT sparse protocol is SO much nicer to work with [Next page](https://internals.rust-lang.org/t/cargo-sparse-protocol-feedback-thread/18234.md?page=2)