provide hook for overriding print

[ssbarnea]

I am working on implementing a report plugin which should be able to produce different output files with results of tox executions, HTML and JSON being main focus.

Still, because at this moment tox makes use of blunt print(), I am unable to to capture its calls in order to build the final report (which is expected to include console output produced by tox).

Details

I am looking to use https://pypi.org/project/rich/ as it can already record console output and export it as HTML. As I doubt you are interested into making rich part of tox core, I need to find a solution for doing this from inside a plugin.

I guess if tox would allow a hooked-print, this could be addressed. Also having a centralized way of dealing with console output would clearly help tox.

@gaborbernat Would you be against a PR that adds support for such a hook?

[gaborbernat]

I'd not add this complication to tox 3, tox 4 uses the logging framework so you'd be to customize the logging handlers there. That being said I've been side-tracked with virtualenv/build issues, so the rewrite hasn't seen progress in the last month.

[ssbarnea]

As I do love tox and care about its future, I would be very happy to join your effort around tox refactoring it. I know that it was postponed for more than an year and I wonder if would not make more sense to work on it in small steps directly on the main branch. The main idea is to avoid the v2 syndrome (where the rewrite does not succeed due to being a too bid endeavor).

[gaborbernat]

There's a lot of breaking changes. I'd not give up on the rewrite just yet, give me till the end of the year 🤔 To be fair the last half-year delay was because some part of core tox was moved within a rewrite to the virtualenv.

[ssbarnea]

In fact it may be possible to avoid the hook issue if we manage to get the output of executed commands captured. For some reason output member seems to be None for executed commands. If I find a way to force tox to capture it, it may be enough for implementing the report (it will not be the same as tox output, but as long I do have output for executed commands, it will be perfect).

[gaborbernat]

tox doesn't capture the output of the commands, and cannot really because the stdout/stderr often is directly linked to the caller tty stdout/stderr. This is one of the things the refactor solves, see https://github.com/tox-dev/tox/blob/rewrite/src/tox/execute/api.py#L62. I have some thread-based pipe readers, but after getting to that now I feel like it should be asyncio, so I want to switch to that.

[ssbarnea]

I guess that if we would have python_requires >= 3.6, it would not be hard to add this.

On my projects, one of the first things I did recently was to remove support for old python, before implementing any other changes. Merged this to master, even made a X.Ya0 pre-release. If anyone wanted changes they would have to use pre-release version, which also assured that there is a small group of users that do test the bleading edge. Would such approach work for tox?

[gaborbernat]

Yes, that's the idea with the rewrite branch. It does already supports python3.6+ only. I need to work probably a week on it to get it to an alpha state when we can start releasing tox-4.0.0a1 and iterate from there.

[ssbarnea]

If you need help, count me in. I am ready to sacrifice a whole weekend only for tox.

[gaborbernat]

Let me get back to you in two to three weeks and see if I can get into a place where we can iterate on this together. The current state was a bit overambitious, so first I need to cut some parts of what we have to build iteratively. I'll spend the free time I have in the following weeks to work on this. If not feel free to ping me directly.

[gaborbernat]

tox 4 prints out content via the logging framework; so you can use that now.