Can't use sparse registry mirror #487
Comments
|
Interesting, thanks for the report! I've never used registry mirrors, is there somewhere I can read about what benefits they provide and in what circumstances they get used?
The error message seems to indicate that, for this configuration, the underlying The underlying code in question is here: If you've double-checked your configuration and have found it correct, would you mind chatting with the |
|
I think it's more about the sparse protocol than the mirrors. By default, if I'm only using the sparse index of crates.io, it'll fetch the git repo automatically. However for custom registries that only contains sparse index, it'll just assume it's a git repo and failed to fetch HEAD. |
|
Ah interesting. I'm not sure if this is a fundamental limitation of Would you mind opening a linked issue in the |
|
For now it should be using the sparse protocol by default (which |
|
These are good points. I think it'd be better if the I can ask the maintainers of |
|
It seems that the sparse index functionality in |
obi1kenobi
added
A-cli
|
Perhaps related to #160 as well. |
|
crates_index is now unmaintained. frewsxcv/rust-crates-index#132 |
|
Thanks for the heads-up. That's unfortunate :(
…On Sun, Jul 23, 2023, 9:33 AM Pavan Kumar Sunkara ***@***.***> wrote:
crates_index is now unmaintained. frewsxcv/rust-crates-index#132
<frewsxcv/rust-crates-index#132>
—
Reply to this email directly, view it on GitHub
<#487 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAR5MSVXCD5K6IWT6TICF2DXRUR3ZANCNFSM6AAAAAA2EWL23I>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Normally I'm not "that guy", but in light of frewsxcv/rust-crates-index#132, I thought I would mention that I have been working on an alternative to Notably, the use case mentioned here is supported by The code would be roughly: impl RustdocFromRegistry {
pub fn new(target_root: &std::path::Path, config: &mut GlobalConfig) -> anyhow::Result<Self> {
let crates_io_url = tame_index::index::IndexUrl::crates_io(
None, // unless you want to override the config root to something other than the current directory
None, // unless you want to override cargo home
None, // unless you want to override the cargo version
)?;
Ok(Self {
target_root: target_root.to_owned(),
version: None,
index: tame_index::index::ComboIndexCache::new(IndexLocation::new(crates_io_url))?,
})
}
fn load_rustdoc(
&self,
config: &mut GlobalConfig,
rustdoc_cmd: &RustdocCommand,
crate_data: CrateDataForRustdoc,
) -> anyhow::Result<PathBuf> {
let crate_ = self.index.cached_krate(crate_data.name.try_into().expect("published cargo crate somehow had an invalid name")).with_context(|| {
anyhow::format_err!(
"{} not found in registry (crates.io). \
For workarounds check \
https://github.com/obi1kenobi/cargo-semver-checks#does-the-crate-im-checking-have-to-be-published-on-cratesio",
crate_data.name
)
})?;
...
}
}I guess one wrinkle is that tame-index uses |
|
That looks quite nice, thanks for mentioning it and showing code! I'm not sure I understood the git caveat at the end. Is the issue that users using a git registry wouldn't benefit from a local cache? Or is the problem something else? Overall this is quite tempting to switch to. It seems like we'd get less complexity, more functionality, and maintained dependency. I'd love to understand the git caveat better, but assuming it's not a major issue I'd love to make the switch! |
|
Well the current code is doing an update of the index, which is only available if the My use case for cargo-deny isn't impacted by this because cargo_metadata is always executed before index operations so the git/sparse index is always guaranteed to have .cache entries for all crates returned by the cargo_metadata call. If you wanted to keep that functionality you could enable the git feature, but it would bloat compile times and binary artifacts since git2 and gix would be both present. |
|
Ah I see. I think we have to be able to update the index, since we need to find historical versions of a crate from the index etc. I'm not too worried about compile times, since many / most users just use the prebuilt binaries that get generated on every release. How would updating the index work after enabling the git feature? Any chance you might be open to making a PR? It seemed like you got 99% of the way there in the example you gave, and you know way more about all this than I do so I trust you more than I trust myself on this 😅 |
|
Sure, I can do that. |
- Add helpers to GitError - Make gix and reqwest exported via crate::externals While working on a PR to resolve obi1kenobi/cargo-semver-checks#487, that crate was looking at the error for git operations to determine if they should be retried, which is....unfortunately way more complicated with gix. So this just adds helper methods on GitError to make that use case nicer.
Steps to reproduce the bug with the above code
I'm having this config for the mirror of crates.io:
Actual Behaviour
cargo semver-checks check-releasefailed with:Expected Behaviour
Checks normally
Generated System Information
Software version
cargo-semver-checks 0.22.1
Operating system
macOS 13.4.1 (Darwin 22.5.0)
Command-line
cargo version
Compile time information
Build Configuration
No response
Additional Context
No response
The text was updated successfully, but these errors were encountered: