On 16/02/2022 17:41, Jean-Paul Calderone wrote:
>
> On Fri, Feb 11, 2022 at 5:36 PM Jean-Paul Calderone
> <exarkun@twistedmatrix.com <mailto:exarkun@twistedmatrix.com>> wrote:
>
> I know that you can hack around this situation roughly like this:
>
> python -m coverage run -m twisted.trial ...
>
> but this has some shortcomings.
>
> 1. If trial --coverage exists shouldn't it be the *good* option?
> 2. python -m coverage run -m twisted.trial -jN ... is a bad time.
> How about some coverage measurement that's multi-core friendly?
> It's a /real/ drag going from a 30 second no-coverage test run
> using 16 cores to a 15 minute coverage-measuring run on a single
> core.
>
> Does anyone agree that this is something short of an ideal
> situation? Is anyone interested in helping address it?
>
> Anyone?
At this point, it feels like any available energy could be more usefully
employed in getting a pytest plugin that really supported the Twisted
reactor in place. Re-inventing wheels like coverage just doesn't seem
sensible at this point.
Thanks for this input Chris. Personally, I have no interest in pursuing work on integrating Twisted and pytest at this time - so I'll leave that to others (given the number of other posts in this thread that are about pytest and not trial, I suppose there is interest in that direction).
Considering the lack of posts from people interested in doing the work on trial (but thanks, glyph!) for now I will conclude that indeed trial does not have much of a developer community behind it - so I will probably not immediately make plans to undertake any serious efforts to maintain or improve it myself (since I doubt that I have the resources to meaningfully accomplish the necessary work on my own).
I've noticed trial itself routinely leaks failures across tests,
resulting in some random test down the line spuriously failing. I've
hacked up tooling to run `trial -u` for 10s for each test case to try
and find these happening, but feels like something the test runner
should really cater for.
This is neither here nor there but this sounds like what `--force-gc` is for and I've almost always had success attributing a failure to the correct test using this flag. This is exactly the kind of poor developer experience that I would love to work with a team of folks on improving, though.
I guess a lot of this, and indeed a non-testing use case I have, would
be served be asyncio-style event loops rather than one single monolithic
and unrestartable reactor.
The fact that trial shares its reactor with test code is another area where trial is lacking, certainly.
This isn't meant to come across as negatively as it may well seem;
there's a reason I haven't ripped Twisted out of the major project I'm
involved in where it's used, but Twisted as a whole and trial in
particular really are feeling their 20yrs of age ;-)
I'm not sure this is so much about age as about lack of interest and lack of maintenance. I am certain that Twisted as a whole and trial could quite readily have many of their rough edges smoothed out - if only anyone cared to try.
Jean-Paul