Skip to content

Doc builder occassionally silently fails due to missing target #543

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
bgamari opened this issue Sep 15, 2016 · 7 comments
Closed

Doc builder occassionally silently fails due to missing target #543

bgamari opened this issue Sep 15, 2016 · 7 comments

Comments

@bgamari
Copy link
Contributor

bgamari commented Sep 15, 2016

Much of the missing documentation on Hackage appears to be due to cabal failing to find an install plan, due to the target package apparently being missing from the package index. For instance, clock-0.7.2 failed with,

Resolving dependencies...
cabal: Could not resolve dependencies:
next goal: clock (user goal)
rejecting: clock-0.7.1.1, 0.7.1, 0.6.0.1, 0.6.0, 0.5.2, 0.5.1, 0.5.0.1,
0.5.0.0, 0.4.6.0, 0.4.5.0, 0.4.4.0, 0.4.3.0, 0.4.2.0, 0.4.1.3, 0.4.1.2,
0.4.1.1, 0.4.0.1, 0.3, 0.2.0.0, 0.1.2.1, 0.1.2, 0.1.1, 0.1 (global constraint
requires ==0.7.2)
Dependency tree exhaustively searched.

To make matters worse, the package is stuck in "docs pending" state indefinitely after this happens.

@bgamari bgamari self-assigned this Sep 15, 2016
bgamari added a commit to bgamari/hackage-server that referenced this issue Sep 15, 2016
I've been noticing a fair number of Hackage packages lacking
documentation due to apparently transient issues (e.g. somehow a package
entering the build queue despite having no entry in the package index,
see haskell#543).

Here we add a simple retry policy; attempting to build a failing package
up to a given number of attempts. The number of failures is now
persisted in the failure file.
@hvr
Copy link
Member

hvr commented Sep 15, 2016

Ok, so if I understand this right, the doc-builder polls http://hackage.haskell.org/packages/docs to figure out what to do next,

...and that list can easily contain packages which have not yet entered the 01-index.tar.gz (which is obviously needs some time to be computed and can easily lag behind several seconds; I've seen this myself after package uploads or edits that it takes several seconds).

I think the doc-builder should simply filter out packages from the doc-index for which there isn't a 01-index.tar entry yet. This is easily accomplished.

@bgamari
Copy link
Contributor Author

bgamari commented Sep 16, 2016

Herbert Valerio Riedel [email protected] writes:

I think the doc-builder should simply filter out packages from the
doc-index for which there isn't a 01-index.tar entry yet. This is
easily accomplished.

I'll admit I'm not sure I see the "easily" part here. Doesn't the
package repository business live in cabal-install, which we cannot link
against?

Regardless, I still suspect that having some sort of retry policy could
only help things.

@hvr
Copy link
Member

hvr commented Sep 16, 2016

@bgamari you don't need to link into cabal-install; cabal-install writes out an easy to parse textual index file ~/.cabal/packages/hackage.haskell.org/00-index.cache:

pkg: Crypto 3.0.3 b# 3
pkg: HDBC 1.0.1 b# 13
pkg: HDBC-odbc 1.0.1.0 b# 15
pkg: HDBC-postgresql 1.0.1.0 b# 18
pkg: HDBC-sqlite3 1.0.1.0 b# 21
pkg: darcs-graph 0.1 b# 24
...

the retry policy is useful in addition of course...

@bgamari
Copy link
Contributor Author

bgamari commented Sep 16, 2016

Herbert Valerio Riedel [email protected] writes:

@bgamari you don't need to link into cabal-install; cabal-install writes out an easy to parse textual index file ~/.cabal/packages/hackage.haskell.org/00-index.cache:

Ahh, I see. I don'u suppose there is a parser for this format available
in Cabal?

@hvr
Copy link
Member

hvr commented Sep 18, 2016

@bgamari no (because Cabal the lib doesn't know about repository indices), there's a parser inside cabal-install's code though. But that is overkill, since the general idea here is that all you need to parse is lines that begin with pkg: and ignore all else, and for those the syntax is:

"pkg:" <pkgname> <pkgver> {<tag> <val>}

so all you have to do is apply words to each line, and see if the first list element is "pkg:", and if that's the case use the 2nd and 3rd list element as package name & version.

@bgamari
Copy link
Contributor Author

bgamari commented Oct 3, 2016

This strikes me as terribly ugly, but I'll do it. This is precisely the reason why I think it would be helpful if cabal-install would split out its functionality into a few loosely coupled libraries. This sort of reinventing the wheel is fragile and unnecessary.

bgamari added a commit to bgamari/hackage-server that referenced this issue Oct 7, 2016
I've been noticing a fair number of Hackage packages lacking
documentation due to apparently transient issues (e.g. somehow a package
entering the build queue despite having no entry in the package index,
see haskell#543).

Here we add a simple retry policy; attempting to build a failing package
up to a given number of attempts. The number of failures is now
persisted in the failure file.
bgamari added a commit to bgamari/hackage-server that referenced this issue Oct 7, 2016
Due to caching sometimes the package repository state may lag behind the
documentation index. Consequently, we make sure that the packages we are
going to build actually appear in the repository before building. See
Issue haskell#543.
bgamari added a commit to bgamari/hackage-server that referenced this issue Oct 7, 2016
Due to caching sometimes the package repository state may lag behind the
documentation index. Consequently, we make sure that the packages we are
going to build actually appear in the repository before building. See
Issue haskell#543.
bgamari added a commit to bgamari/hackage-server that referenced this issue Oct 12, 2016
Due to caching sometimes the package repository state may lag behind the
documentation index. Consequently, we make sure that the packages we are
going to build actually appear in the repository before building. See
Issue haskell#543.
bgamari added a commit to bgamari/hackage-server that referenced this issue Oct 17, 2016
Due to caching sometimes the package repository state may lag behind the
documentation index. Consequently, we make sure that the packages we are
going to build actually appear in the repository before building. See
Issue haskell#543.
@gbaz
Copy link
Contributor

gbaz commented Aug 19, 2017

@bgamari I think the linked commits fixed this issue, no? closing for now, lmk if i'm mistaken.

@gbaz gbaz closed this as completed Aug 19, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants