On Sun, Feb 20, 2022 at 1:44 PM Chris Withers <ch...@withers.org> wrote:
> > On 16/02/2022 17:41, Jean-Paul Calderone wrote: > > > > On Fri, Feb 11, 2022 at 5:36 PM Jean-Paul Calderone > > <exar...@twistedmatrix.com <mailto:exar...@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
_______________________________________________ Twisted mailing list -- twisted@python.org To unsubscribe send an email to twisted-le...@python.org https://mail.python.org/mailman3/lists/twisted.python.org/ Message archived at https://mail.python.org/archives/list/twisted@python.org/message/OTIWK7N6NEL47ROD3F6A5C33WXXD2BXJ/ Code of Conduct: https://twisted.org/conduct
