-
Notifications
You must be signed in to change notification settings - Fork 112
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
Unconditionally query crates.io HTTP index for publish status #693
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -111,7 +111,7 @@ pub fn publish( | |
} | ||
|
||
pub fn wait_for_publish( | ||
index: &mut crates_index::Index, | ||
index: &mut tame_index::index::ComboIndex, | ||
name: &str, | ||
version: &str, | ||
timeout: std::time::Duration, | ||
|
@@ -122,8 +122,10 @@ pub fn wait_for_publish( | |
let sleep_time = std::time::Duration::from_secs(1); | ||
let mut logged = false; | ||
loop { | ||
if let Err(e) = index.update() { | ||
log::debug!("crate index update failed with {}", e); | ||
if let tame_index::index::ComboIndex::Git(gi) = index { | ||
if let Err(e) = gi.fetch() { | ||
log::debug!("crate index update failed with {}", e); | ||
} | ||
} | ||
if is_published(index, name, version) { | ||
break; | ||
|
@@ -145,12 +147,21 @@ pub fn wait_for_publish( | |
Ok(()) | ||
} | ||
|
||
pub fn is_published(index: &crates_index::Index, name: &str, version: &str) -> bool { | ||
let crate_data = index.crate_(name); | ||
crate_data | ||
.iter() | ||
.flat_map(|c| c.versions().iter()) | ||
.any(|v| v.version() == version) | ||
pub fn is_published(index: &tame_index::index::ComboIndex, name: &str, version: &str) -> bool { | ||
match index.krate(name.try_into().expect("crate name is invalid"), true) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does this call always do a network operation for sparse index? Inside of cargo, we unconditionally cache lookups in-memory (and on-disk) and it requires an explicit call to force a new lookup. If the caller has to explicitly decide to do a If this doesn't always do a network operation, then this is broken for sparse index as we need to ensure we get the latest published status. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For git it does no network I/O only reading from the cache or git blob if the cache is outdated, for sparse it always does a network call, using the local cache entry to set the e-tag so that the response will only be 200 if the crate metadata has been updated. |
||
Ok(Some(crate_data)) => crate_data | ||
.versions | ||
.into_iter() | ||
.any(|iv| iv.version == version), | ||
Ok(None) => false, | ||
Err(err) => { | ||
// For both http and git indices, this _might_ be an error that goes away in | ||
// a future call, but at least printing out something should give the user | ||
// an indication something is amiss | ||
log::warn!("failed to read metadata for {name}: {err:#}"); | ||
false | ||
} | ||
} | ||
} | ||
|
||
pub fn set_workspace_version( | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,24 @@ | ||
pub(crate) fn open_crates_io_index() -> Result<tame_index::index::ComboIndex, crate::error::CliError> | ||
{ | ||
let index = tame_index::index::ComboIndexCache::new(tame_index::IndexLocation::new( | ||
tame_index::IndexUrl::crates_io(None, None, None)?, | ||
))?; | ||
|
||
let index = match index { | ||
tame_index::index::ComboIndexCache::Git(gi) => { | ||
tame_index::index::RemoteGitIndex::new(gi)?.into() | ||
} | ||
tame_index::index::ComboIndexCache::Sparse(si) => { | ||
tame_index::index::RemoteSparseIndex::new( | ||
si, | ||
tame_index::external::reqwest::blocking::Client::builder() | ||
.http2_prior_knowledge() | ||
.build() | ||
.map_err(tame_index::Error::from)?, | ||
) | ||
.into() | ||
} | ||
}; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not too thrilled with the amount of ceremony from this API... There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Understandable, but this API was a response to That being said it's trivial to to add helper functions to tame-index to open the crates.io index with zero knobs. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. A lot of libraries have a builder for complex operations and then have a convenience |
||
|
||
Ok(index) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the locking scheme?
Granted, I'm not correctly handling it for
crates_index
today but its what has stopped me from migrating from v1 to v2 incargo-edit
is the lack of clarify on this.In
cargo-edit
, we've had to implement a retry loop for locking. I see that tame-index advertises (b)locking support but its unclear to me which locks are involved seeing as tame-index is directly reading and manipulating internal cargo caches (not really thrilled with that btw). Is it using the same locking policy as cargo?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the opening of a git index is locked via gix's mechanism, but tame-index doesn't currently support the global package lock mechanism that cargo uses. I'll open an issue to add that eventually, but I think the easier thing to do for this crate is to simply do one of the options I mentioned in the PR, and just only use the sparse index, and do zero disk operations at all, and remove the gix dependency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm hesitant about the idea of exclusively doing network operations to the point that I'd need a strong justification to move this PR forward.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is that a problem? The current code is doing far more network I/O due to always performing a git fetch, changing it to do a single HTTP request for the crate being released with its etag means drastically reduced and faster checking for the publish status of the crate.