> On Feb 21, 2022, at 6:40 AM, Jean-Paul Calderone <exar...@twistedmatrix.com> > wrote: > > On Sun, Feb 20, 2022 at 1:44 PM Chris Withers <ch...@withers.org > <mailto: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> > > <mailto: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’m in a similar place myself. I could probably put more effort forth if we could get a bit more of a small commitment from more other developers. I do not want to spend my time as a full-time unpaid twisted maintainer, or simply slogging through reviewing old tickets while never developing any interesting new features myself. But, it seems like unless I do, then my own feature development will simply languish forever at the end of a year-long queue. It makes me wish we could have a sort of open source mutually-assured maintenance system, where we all put in some number of hours and get some small reward (like bragging rights, a little badge?) out of meeting that commitment. But that also requires some volunteers[1] to go build it. This trial maintenance is also something I’m definitely interested in, but I don’t think just a small commitment from me and JP would be quite enough to get it somewhere meaningful. [1]: not me > 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. Yeah, Trial could absolutely be more discoverable. And probably have some more facilities for managing leaks of global reactor state, to make it clearer what’s going on when you get this sort of inscrutable mess of a failure. > 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. I think it’s more about the trying than the caring. I get the sense that folks do still care about Twisted but most of the core people are quite busy. So is anyone waiting out there in the wings interested in doing some more of the day-to-day of just reviewing tickets, responding to contributors, and keeping discussions like this one going? i.e. recording mailing list & chat consensus on tickets, checking to make sure PRs are getting updated, etc? I know the project has a bit of an intimidating reputation due to some of its more complex areas, but quite a lot of what needs to be done here is quite simple and could be a great learning opportunity. -g
_______________________________________________ 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/X4HABBD7AFJSPBBTZWPRGQQO7JO26DSL/ Code of Conduct: https://twisted.org/conduct
