capture: combine or line-order intersparse stdout and stderr

[ssbarnea]

At this moment pytest capture is not able to combine stdout and stderr lines in a chronological order, thus the capture is separated. This means that that on larger outputs it is impossible to identify where did the stderr lines originated from (example ansible output, where warnigns are sent to stderr).

[RonnyPfannschmidt]

it might make sense to also integrate logging there in some manner,

being order aware is a critical thing in various setups for comprehending whats happening

[nicoddemus]

Hi,

How would that look like, a new cmdline option? Also how would that affect cap* fixtures and the existing sys and fd modes?

[RonnyPfannschmidt]

its not clear to me how those would interact the outerr return values turn senseless in the face of a merge to one fd

[nicoddemus]

I'm thinking merging stdout into stderr (similar to how subprocess does it) would mean that stderr would never capture anything.

Thinking more about that, perhaps cap* fixtures shouldn't be affected by this command-line at all, as plenty of tests in a test suite using those fixtures would then start failing if you used the command-line option.

[blueyed]

Just for info: I think separate threads could be used to capture stdout/stderr separately and merge them. This is what I've used with auto-stdin handling with/via ptys.

[RonnyPfannschmidt]

i don think we can get correct output order that way unless buffering and locking is strangely controlled, im -1 on trying with htreads

[blueyed]

Yes, it's not really straightforward nor easy, but would work - and there appears no better method if you do not want to merge it into a single stream really AFAIK.

[RonnyPfannschmidt]

practically speaking for pure python its reasonably sensible to just use a buffered pipe and wire up line receivers that receive lines with timestamps plus making the streams flush eagerly with a sleep(0) thrown in to trigger other threads, but will still create potential order flips