Skip to content

Fix CI #365

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
blueyed opened this issue Nov 22, 2019 · 4 comments · Fixed by #351
Closed

Fix CI #365

blueyed opened this issue Nov 22, 2019 · 4 comments · Fixed by #351

Comments

@blueyed
Copy link
Contributor

blueyed commented Nov 22, 2019

CI is currently broken.

One of the main reasons might be pytest-dev/pytest-xdist#448 (comment), but it looks like there is more.

This is meant to keep track of issues in this regard, and IMHO should have high priority, since it makes even trivial PRs unnecessarily "red" / failing, and even the latests PRs and releases have been done with red CI.

@ionelmc
Copy link
Member

ionelmc commented Nov 26, 2019

Ooooof. Well, there are 2 nasty things going on that take time to figure out:

The xdist problem from pytest-dev/pytest-xdist#448 (comment) - we either drop support for un-collocated mode (ssh/popen xdist) or spend time debugging.

Python3.8's multiprocessing is broken (well, more than the usual multiprocessing being architecturally broken) - there's a simple reproducer in https://bugs.python.org/issue38227

I guess we can drop the ball and skip multiprocessing tests on 3.8 and advise users to stop using garbage like multiprocessing? Or spend tons of time debugging.

I guess we could try the technique in https://github.com/nedbat/coveragepy/blob/master/coverage/multiproc.py but I doubt it would be as reliable.

@blueyed
Copy link
Contributor Author

blueyed commented Nov 26, 2019

advise users to stop using garbage like multiprocessing

Can you elaborate? I've thought about using it with / adding it to pytest by default, and there's a WIP for xdist also to use it (pytest-dev/pytest-xdist#479).
What would you recommend instead?

@ionelmc
Copy link
Member

ionelmc commented Dec 6, 2019

Multiprocessing is over-engineered. It's the inevitable result of trying to produce something that works on all platforms. Read the sourcecode and shudder in horror :)

It's also maintained badly - the response in the cpython bugtracker is simply disappointing.

So I wouldn't use it for those two reasons.

@ionelmc
Copy link
Member

ionelmc commented Dec 9, 2019

Good news everyone: the xdist problem is going to be fixed with a new xdist release.

Regarding the python 3.8 problem ... I guess we could just make the signal setup be no-op on python3.8 and skip tests for now?

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