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
{{ message }}
Repository navigation
Sparse-registry fetching total size keeps increasing #10820
One thing I noticed is that the fetching need to go through several loops now, previously it just fetch until 100% then done, but now when it reached 100%, then it had to fetch another time again, and the total stuff needed to fetch which keeps increasing (1 -> 10 -> 50 -> 100 -> 130) resulting in the progress decreasing, feels weird.
I feel like the total should be - until there is a definite answer to the total number that needs to fetch then only show it rather than keep increasing it.
Steps
rustup update nightly
cargo +nightly -Z sparse-registry update
Possible Solution(s)
A way to improve that in the registry would be to on publish, provide an optional expected_dep_forest_size from the number of transitive dependencies used at publish time. This number could be used to provide a reasonable progress estimate quickly.
Activity
arlosi commentedon Jul 6, 2022
This is expected behavior, but I understand it's confusing to have progress go backwards.
@rustbot modify labels: -C-bug +C-enhancement
rustbot commentedon Jul 6, 2022
Error: The feature
relabelis not enabled in this repository.To enable it add its section in the
triagebot.tomlin the root of the repository.Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #t-infra on Zulip.
arlosi commentedon Jul 6, 2022
Some additional ideas on what we could do.
Remove the progress bar
X/Ystatus.Ywill still change as deps are discovered.Include an estimate of the dependency graph size when publishing
Attempt to run the resolver using cached metadata to get an estimate
Use the lockfile to get an estimate of the total number of dependencies
pickfire commentedon Jul 7, 2022
That sounds pretty much the same issue to me, it's basically a progress bar that never ends, I rather it be
X/-orX/∞if we don't know it yet.arlosi commentedon Jul 7, 2022
Maybe instead of
35/38something like:pickfire commentedon Jul 8, 2022
Or maybe
X/N+3then until it is confirmed,X/Yarlosi commentedon Jul 8, 2022
What do you mean by confirmed? Each dependency that's fetched could potentially require additional dependencies that aren't fetched yet.
pickfire commentedon Jul 9, 2022
Confirmed as in cargo knows that there won't be any additional dependencies.
Auto merge of #11068 - arlosi:progress, r=epage
Auto merge of #11498 - dtolnay-contrib:relabel, r=ehuss