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

newly updated crates are not built if there are too many of them #89

Closed
Byron opened this issue Dec 24, 2016 · 10 comments · Fixed by #90
Closed

newly updated crates are not built if there are too many of them #89

Byron opened this issue Dec 24, 2016 · 10 comments · Fixed by #90

Comments

@Byron
Copy link
Member

Byron commented Dec 24, 2016

I have recently published a great amount of crates in an automated fashion, and noticed that docs-rs didn't really catch up with them.

screen shot 2016-12-24 at 22 16 42

An example would be the google-logging2 crate, which exists in version 1.0.1, whereas docs.rs still shows it as version 1.0.0.

A glimpse into the code indicates that docs.rs detects newly updated crates by looking at the .just_updated field of the crates.io summary endpoint (see code), which appears to be a problem if there are many new releases in an interval shorter than the one used to query the endpoint.

As I just now moved all my links to point to docs.rs, it would be great if we could find out what could be done to alleviate the issue :).

Thank you.

@Byron Byron changed the title Could it be that newly updated crates are missed? newly updated crates are not built if there are too many of them Dec 25, 2016
@Byron
Copy link
Member Author

Byron commented Dec 25, 2016

I am actually working on a PR to fix this. The idea is to clone the crates index and keep track of the last commit we have seen.
Each time we try to get information about changed crates, we will fetch latest and diff the changes. That way we will never be able to miss anything, as we are then based on the only source of truth.

I will also setup a WIP PR in a moment so you can stay informed on the progress.

@onur
Copy link
Member

onur commented Dec 25, 2016

Thanks for reporting.

This is similar to #84. Since docs.rs started getting new crate list from crates.io/summary this issue also occurred. docs.rs is checking new crates every 5 minutes and crates.io/summary is only returning last updated 10 crates. If crates.io gets more than 10 uploads in 5 minutes, docs.rs is skipping them.

I will revert this changes and start getting new crates from crates.io-index repository again.

Leaving this commit id for reference: 712dcb6 #77 fixed link.

@onur onur added the important label Dec 25, 2016
@Byron
Copy link
Member Author

Byron commented Dec 25, 2016

Thanks for elaborating on this!
Does it mean you don't need me to work on this? Actually I would love to get involved, but of course only if there is no code to do this lying around already.

@Byron
Copy link
Member Author

Byron commented Dec 25, 2016

Ah, I see there is code for that already. However, I wouldn't mind giving it a try too. Can you give me an advise on how you would want me to proceed?

@onur
Copy link
Member

onur commented Dec 25, 2016

Thanks for offering help! I changed old code because it wasn't working properly. You can see the old code from here: queue.rs.

I have been trying to parse DiffLine with Diff::print but this seems really wrong.

Maybe you can figure out how to get new crates properly by using git2 crate and crates.io-index. There must be a better way or approach to do this but I have no idea.

@Byron
Copy link
Member Author

Byron commented Dec 25, 2016

Alright :)! I happen to have been working with git internals quite a bit in the past, and I always wanted to work with it once again from Rust.
I have already seen the previous issues and code and will work on a new implementation, keeping a close eye on leaked file handles.
Shall keep you posted!

@Byron
Copy link
Member Author

Byron commented Dec 25, 2016

Here is the first version of the crates-index-diff crate. It's already providing all the functionality you would need.
Tomorrow I will push it towards 1.0 (refactoring, cleanup, docs), and prepare a PR for docs.rs to use it.
Please feel free to comment on it already.

@onur
Copy link
Member

onur commented Dec 25, 2016

@Byron this seems really promising, thank you very much.

There is only one issue. Docs.rs dependencies (cargo, hyper and iron especially) are using openssl 0.7 and latest git2 crate started using openssl 0.9. Currently we can't use both of them together. We have to use git2 0.5 until hyper starts using openssl 0.9. There is an ongoing PR for hyper: hyperium/hyper#975. But updating iron to 0.4 in docs.rs will require some work.

So basically your crate must depend on git2 0.5 for now, we can update it later when all dependencies supports openssl 0.9. BTW your crate is fully compatible with git2 0.5.

@Byron
Copy link
Member Author

Byron commented Dec 26, 2016

Version 1.0 of the crate has now been released. It's dependency to git was already adjusted to match the requirements of docs.rs.

Now I am working on a quick CLI to show how it is used, and to have it ready in case you would like to keep the git-related accesses out of process (and also because I want it :)).

@Byron
Copy link
Member Author

Byron commented Dec 26, 2016

Alright, the crates-io-cli is ready, and allows to test manually use the functionality of the crates-index-diff crate.

Next up is a PR to actually use the new functionality in docs.rs.

Byron referenced this issue in Byron/crates-index-diff-rs Dec 26, 2016
@onur onur closed this as completed in #90 Dec 26, 2016
onur added a commit that referenced this issue Dec 26, 2016
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.

2 participants