Skip to content

Assume backend/optional package checks fail after defined timeout #3444

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.

Sign up for GitHub

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

Jump to bottom
Closed
JDWarner opened this issue Aug 31, 2014 · 8 comments
Closed

Assume backend/optional package checks fail after defined timeout #3444

JDWarner opened this issue Aug 31, 2014 · 8 comments
Assignees
@jenshnielsen
Labels
status: confirmed bug
Milestone
v1.4.x

Comments

@JDWarner
Copy link

Over in scikit-image we're having some trouble with our Travis build, and it appears to be due to the matplotlib optional backend package check for Qt4 entering a subprocess and never returning under the Travis system Python (3.2.3). This results in an eventual Travis timeout.

See the bottom of this build log: https://travis-ci.org/JDWarner/scikit-image/jobs/34035472

The reason this happens is unclear and it would be ideal if this worked (as PyQt4 is present in that 3.2 build), but the real problem is that this can completely tank a CI build or install. Ergo, we recommend a timeout (perhaps ~15 seconds) for checking [optional] build packages.
@jenshnielsen
Copy link
Member

I discussed this with @JDWarner at the euroscipy sprint.I have seen a similar issue with a broken pygobject hanging the setup script

@jenshnielsen
Copy link
Member

#3443 is a duplicate of this

@jluttine
Copy link

jluttine commented Sep 1, 2014

I've experienced this problem too with my project. Just in case it helps, I forked matplotlib and added Python 3.2 to Travis tests. Here is the failing output:
https://api.travis-ci.org/jobs/34094194/log.txt?deansi=true
If this was just repeating the same info, then sorry for spamming.

@jluttine jluttine mentioned this issue Sep 1, 2014
Closed
@jenshnielsen
Copy link
Member

@jluttine thanks for sharing, Looks a bit different from the scikit image one so it is useful.

@jenshnielsen jenshnielsen added this to the v1.4.x milestone Sep 1, 2014
@jenshnielsen jenshnielsen self-assigned this Sep 1, 2014
@tacaswell
Copy link
Member

@jluttine As a side note, we intentionally dropped testing 3.2 and do not claim to support it (see #3192 )

@jenshnielsen
Copy link
Member

While @tacaswell is right I would like to try to get to the bottom of this. I don't like that the setup script can hang like this and suspect that this might have more to do with the specific pyqt installation than the python version

@tacaswell tacaswell modified the milestones: v1.4.x, v1.4.1 Sep 3, 2014
@tacaswell tacaswell modified the milestones: v1.4.1, v1.4.x Sep 30, 2014
@tacaswell
Copy link
Member

Not willing to block 1.4.1 on this issue, re-milestoning to 1.4.x.

@blink1073 blink1073 mentioned this issue Oct 13, 2014
Merged
This was referenced Oct 29, 2014
Closed
Merged
@jenshnielsen
Copy link
Member

I believe this was fixed by #3741 please reopen if that is not the case

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jenshnielsen jenshnielsen

Labels
status: confirmed bug
Projects
None yet
Milestone
v1.4.x
Development

No branches or pull requests
5 participants
@tacaswell @jenshnielsen @anntzer @JDWarner @jluttine