Skip to content

Registry index paths changed in Rust 1.85.0 #182

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

Closed
UebelAndre opened this issue Jan 10, 2025 · 4 comments · Fixed by #184
Closed

Registry index paths changed in Rust 1.85.0 #182

UebelAndre opened this issue Jan 10, 2025 · 4 comments · Fixed by #184

Comments

@UebelAndre
Copy link
Contributor

In Rust 1.85.0, this crate won't be able to find index locations due to rust-lang/cargo#14917. The crate currently expects sparse+https://index.crates.io/ to map to:

~/.cargo/registry/index/index.crates.io-6f17d22bba15001f/config.json

However, after rust-lang/cargo#14917 Cargo will instead use:

~/.cargo/registry/index/index.crates.io-1949cf8c6b5b557f/config.json

Thus, the directories will be misaligned.

@Byron
Copy link
Collaborator

Byron commented Jan 11, 2025

Thanks for the heads-up! This means less than 6 weeks to prepare for this.

The code creating the sparse index hash seems to be here.

From what I can tell, we'd have to be able to…

  • …produce a local path with the new hash
  • …fallback to a local path with the old hash if the new hash path isn't present

And to do do that, one would have to to start using the rustc-stable-hash = "0.1.1" crate instead of the SipHasher.

Is that analysis correct?

@UebelAndre
Copy link
Contributor Author

From what I can tell, we'd have to be able to…

* …produce a local path with the new hash

Yeah, this makes total sense.

* …fallback to a local path with the old hash if the new hash path isn't present

This feels somewhat optional, at a minimum I think users of this crate should have control over which is used. But if there's an easy way to handle the fallback internally that would be good!

And to do do that, one would have to to start using the rustc-stable-hash = "0.1.1" crate instead of the SipHasher.

Looking at the rustc change I think this is correct.

@Byron
Copy link
Collaborator

Byron commented Jan 11, 2025

This feels somewhat optional, at a minimum I think users of this crate should have control over which is used. But if there's an easy way to handle the fallback internally that would be good!

I think it would be beneficial if existing cache directories would be found if present so unnecessary downloads can be avoided. When no directory was found, which is probably quite rare, I'd say it should prefer the one using the most recent hash though.

Besides that, I think I'd leave all this as implementation detail unless there is demand for making this configurable.

@UebelAndre
Copy link
Contributor Author

I opened #184 but the hash I'm getting from sparse+https://index.crates.io/ does not match what Cargo generates. I don't have any context on the previous hash implementation so wondering if I could get some help finding that root cause.

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

Successfully merging a pull request may close this issue.

2 participants