[WIP] Refactor _getcapture

[blueyed]

This refactors the Capture classes to be more flexible.

The new --capture=tee-sys (#6315)
is rather a flag that could have been also done via --capture-tee, to
later also apply to fd.

This was inspired by looking at it from the point of adding a "duplicate stderr
to stdout" mode (i.e. a single stream), which also is a new mode that can be
applied to both the fd and sys method.

Therefore this handles --capture now as a set of modes (split on dashes).

This does not change any behavior for now, but can be refactored more, and
I might look into adding support for tee-fd then also.

Ref: #6315 (comment)
Ref: #4597

Question: should there also be new fixtures for this, i.e. capteesys?
That would result in 4 new fixtures then though:
"capteefd", "capteefdbinary", "capteesys", "capteesysbinary", and twice as much
again with "single" - i.e. it gets messy with --fixtures etc.
So for this it might make sense to have a fixture that only works as a flag
then (captee), so that you would request capsys and captee.

/cc @csm10495

[RonnyPfannschmidt]

it was intentionally done as own method, as too-fd capture is vastly more difficult than too-sys capture
as it practically needs tee fds to be set up/consumed

as the implementation will vastly differ and cant share logic, using a flag instead of a new implementation name seemed misleading

[blueyed]

@RonnyPfannschmidt
This is an implementation "detail" that does not mean we should not "split --capture on parens", does it?

[blueyed]

I guess with regard to capteesys this is (or should be) similar to using capsys fixture + -s.

[RonnyPfannschmidt]

for the capture fixture, it seems like it would be helpful if it could be turned into one fixture that may be configured by a parameter/marker instead of having many mutually exclusive fixtures

[RonnyPfannschmidt]

side-note, the more tricky implementation that's necessary for a tee-fd is potentially also a gateway to a pty/tee-pty capture backed

[blueyed]

side-note, the more tricky implementation that's necessary for a tee-fd is potentially also a gateway to a pty/tee-pty capture backed

Yes.
You need a thread (or multiple), and also master, slave = pty.openpty() when handling stdin (IIRC), otherwise os.pipe() is fine for stdout/stderr.

[blueyed]

for the capture fixture, it seems like it would be helpful if it could be turned into one fixture that may be configured by a parameter/marker instead of having many mutually exclusive fixtures

That should be the long-term goal, given that there is the tee option now and dup/merge maybe later.
Let's not worry about adding this one (capteesys) as a fixture here then.

[RonnyPfannschmidt]

good point

[blueyed]

Removing "[WIP]".
I think it makes sense to have this for #6690 (review).

[nicoddemus]

LGTM

[nicoddemus]

This empty class is here for type hinting only? Perhaps adding a quick one line docstring mentioning that?

[blueyed]

Yeah, or remove it.
This certainly needs another pass.
I've thought about pulling out the renaming/moving of the new classes only for now, given that combinations are not really needed currently anyway (also because of the "choices" validation).

It might make sense to pick that part into #6690, but there it appears to be unclear still how to do it (at least to me). Will try/look into that later, but might take some time.

[nicoddemus]

OK, thanks

[aklajnert]

@blueyed are you planning to merge it soon? It would be useful to have it before I'll resume work on #6690. Maybe you need some help?

[blueyed]

@aklajnert it's not really clear to me how to proceed here (#6671 (comment)).
Please fee free to either rebase #6690 on this one, and/or include what you find useful from here, but likely better as separate/base commits then.

[blueyed]

@aklajnert I've pulled out #6765, without the generalisation of _getcapure.

[blueyed]

Closing for now, can be revisited later, or pulled into #6690 then.

FWIW _getcapture should be named _get_multicapture, and could be on the module - or a classmethod MultiCapture.from_method, which might be preferred. (=> #6788)