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

cargo upgrade fails to get crates version when using sparse registry #841

Closed
inflation opened this issue Feb 10, 2023 · 11 comments · Fixed by #907
Closed

cargo upgrade fails to get crates version when using sparse registry #841

inflation opened this issue Feb 10, 2023 · 11 comments · Fixed by #907

Comments

@inflation
Copy link

Since there will be no git repo locally after the change to use sparse registry, we need another way to figure out the latest version available.

@epage
Copy link
Collaborator

epage commented Feb 10, 2023

Does it fail in practice from a user changing their config?

From what I understand it shouldn't but I could be wrong.

As for server side, crates.io will continue to support the git registry, so switching to sparse registry is for performance and for alternative registries that drop git registry support.

Personally, I suspect the path to merging into cargo would be the faster / easier route.

@inflation
Copy link
Author

If the user had previously fetched the index, they would be fine. However, the main purpose of sparse registry is to speed up fresh setup, so new users after the change would be clueless because the error message is bad:

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)

From what I heard, cargo is currently on a feature freeze. I'm uncertain if this could make it into cargo before the default change.

@epage
Copy link
Collaborator

epage commented Feb 13, 2023

So this isn't a matter of crates-index not properly handling no registry existing. My guess is the sparse registry and git registry are sharing a path and the git registry needs to handle only the sparse registry being initialized

@epage
Copy link
Collaborator

epage commented Feb 13, 2023

I've tried to find reproduction steps for this to report this upstream but cannot reproduce this.

I've tried

  • rm -rf ~/.cargo/registry and then initializing the index
  • rm -rf ~/.cargo/registry/index/*/.git and then initializing the index

@5225225
Copy link

5225225 commented Mar 4, 2023

If you do rm -rf ~/.cargo/registry, then cargo upgrade (cargo-edit-upgrade 0.11.9) then Ctrl+C it a few seconds later, then try it again, you get that error. Incomplete checkout, I guess?

@ttys3
Copy link

ttys3 commented Mar 22, 2023

If you do rm -rf ~/.cargo/registry, then cargo upgrade (cargo-edit-upgrade 0.11.9) then Ctrl+C it a few seconds later, then try it again, you get that error. Incomplete checkout, I guess?

I got this too.

@aminya
Copy link
Contributor

aminya commented Apr 1, 2023

As a workaround, adding the following to .cargo/config.toml fixes the issue:

# Because cargo-upgrade will fail otherwise
# https://github.com/killercup/cargo-edit/issues/841
[registries.crates-io]
protocol = "git"

https://doc.rust-lang.org/cargo/reference/config.html#registriescrates-ioprotocol

@0atman
Copy link

0atman commented Apr 27, 2023

Just an fyi sparse becomes the default strategy in 1.70.0, due for release on the 1st of June https://releases.rs/docs/1.70.0/

Thanks all for your work!

@stevefan1999-personal
Copy link

Until frewsxcv/rust-crates-index#87 is fixed, we will have no progression

@stevefan1999-personal
Copy link

That was fixed last week, let's go ahead and upgrade it and see if it works

@epage
Copy link
Collaborator

epage commented Jun 25, 2023

To be clear, I would consider that a workaround (moving off of git) rather than a fix to the problem as using a git index at the same time as a parse index should work

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

Successfully merging a pull request may close this issue.

7 participants