pytest-xdist and capture=no fail tests when tests write non-ASCII

[mdengler]

• Include a detailed description of the bug or suggestion

py.test fails to run tests that write non-ASCII when "-s" and "-n" are specified. Similar to #573 and #1178 but a) this is a different symptom; b) this symptom manifests in the latest versions of py.test and pytest-xdist; and c) there is no open issue tracking this behavior.

• pip list of the virtual environment you are using

$ pip list | grep pytest
pytest (2.9.2)
pytest-xdist (1.14)

• py.test and operating system versions

Darwin Kernel Version 14.5.0: Mon Jan 11 18:48:35 PST 2016

• Minimal example if possible

$ cat ./test.py
# -*- encoding: utf-8 -*-
def test_print_some_unicode():
    print u"🙋"

$ py.test ./test.py
=============================================================================== test session starts ===============================================================================
platform darwin -- Python 2.7.8, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: ..., inifile:
plugins: xdist-1.14
collected 1 items

test.py .

=================================================================== 1 passed, 2 pytest-warnings in 0.00 seconds ===================================================================

$ py.test -n1 ./test.py
=============================================================================== test session starts ===============================================================================
platform darwin -- Python 2.7.8, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: ..., inifile:
plugins: xdist-1.14
gw0 C
gw0 [1]
scheduling tests via LoadScheduling

=================================================================== 1 passed, 2 pytest-warnings in 0.34 seconds ===================================================================

$ py.test -n2 ./test.py
=============================================================================== test session starts ===============================================================================
platform darwin -- Python 2.7.8, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir:  ... , inifile:
plugins: xdist-1.14
gw0 C / gw1 C
gw0 [1] / gw1 [1]
scheduling tests via LoadScheduling
=================================================================== 1 passed, 2 pytest-warnings in 0.36 seconds ===================================================================

$ py.test -n2 -s ./test.py
=============================================================================== test session starts ===============================================================================
platform darwin -- Python 2.7.8, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: ..., inifile:
plugins: xdist-1.14
gw0 C / gw1 C
gw0 [1] / gw1 [1]
scheduling tests via LoadScheduling
F
==================================================================================== FAILURES =====================================================================================
_____________________________________________________________________________ test_print_some_unicode _____________________________________________________________________________
[gw0] darwin -- Python 2.7.8 .../python
def test_print_some_unicode():
>       print u"🙋"
E       UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1: ordinal not in range(128)

test.py:3: UnicodeEncodeError
=================================================================== 1 failed, 2 pytest-warnings in 0.36 seconds ===================================================================

[RonnyPfannschmidt]

interesting,

a) its likely this should always fail - investigation is needed as to why the stdio encoding isn't ascii or a not problem when just captureing
b) xdist by design disables the -s switch, i wonder why it got reactivated to begin with

[mdengler]

On 1 Jul 2016, at 00:22, Ronny Pfannschmidt notifications@github.com wrote:
a) its likely this should always fail - investigation is needed as to why the stdio encoding isn't ascii or a not problem when just captureing

I have been using pytest-xdist to run tests whose stdout emits utf-8 for years and do not recall a problem. Perhaps it's because I always set PYTHONIOENCODING=utf-8 when calling py.test.

b) xdist by design disables the -s switch, i wonder why it got reactivated to begin with

I cannot recall when -s was ever disabled for tests run using (local, popen) pytest-xdist - I have always seen stdout/stderr.

We could bisect, etc. but I'd imagine that's fairly academic now.

I tried changing code in xdists's remote.py's final 'if name == ...' block to set os.environ['PYTHONIOENCODING'] = 'utf-8', but that didn't solve the problem. The control flow of how the tests' stdout and stderr flow through remote.py wasn't immediately obvious otherwise I would've tried something better.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[RonnyPfannschmidt]

sorry for the long delay,
first - xdist has to disable -s because it uses stdin/out via execnet in order to control execution

the only thing that does get shown should be stderr if ever

[RonnyPfannschmidt]

oh, and on another note - inside of remote.py you are already past interpreter startup and can no longer affect ioencoding, you can use --tx=popen//env:PYTHONIOENCODING=utf8 for a test run tho

[robnagler]

@RonnyPfannschmidt will pytest-forked support capture?

[RonnyPfannschmidt]

@robnagler pytest-forked cant support capture=no, it must always use capture as its using the forked process stdio to communicated

[robnagler]

@RonnyPfannschmidt Thanks for the response. I understand that the existing implementation works this way. It seems to me you could adopt a different approach, more like ssh, which uses the same channel for stdio and out of band (OOB) communication.

I suspect that the only OOB "packet" that needs to be monitored is "success" of the test. This could be a simple token that gets written to stdout only when the case succeeds. The rest of the output could be passed back to the user.

[RonnyPfannschmidt]

@robnagler possibly - but thats to be implemented in pytest-forked by someone wanting to maintain it,

i don't

[arikkfir]

FYI, I had the same issue (pytest failing on this error) under BuildKite; but adding PYTHONIOENCODING=utf-8 solved this for me.

[nicoddemus]

but thats to be implemented in pytest-forked by someone wanting to maintain it, i don't

@RonnyPfannschmidt should we add a note in pytest-forked's README stating that it is looking for new maintainers? Making that explicit will make it easy for us to get people interested.

[asottile]

hello, first off thank you for the issue!

python 2.x support has ended for pytest core.

we've decided in #7296 to close the python-2-specific issues to free up some space in our backlog. however, in accordance to our python 2.7 and 3.4 support community patches will still be accepted to the 4.6 series to fix bugs for python 2. (so if this issue is important to you and you have a patch to fix it, feel free to make a PR targeting the 4.6.x branch despite this ticket being closed).