On 21/02/2022 14:40, Jean-Paul Calderone wrote:
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 sorry to be brutally honest here, but this covers Twisted, not just trial. All the energy is around asyncio stuff like FastAPI and the stack it's built on. Twisted is great, but feels seriously dated (eg: humpyCase, yield instead of await, trial instead of pytest, "only one event loop that you can't restart") and debugging is hellish. I have a massive amount of respect for the framework, to be clear, but I also understand why there's not much of an active developer community around it: it's not a thing that's fun to work on; 20yrs of history rarely is...
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
Yep, we use --force-gc on all our CI runs, but plenty still leak through. The most robust way I've found is running `trial -u` in a subprocess for 10s per test and "passing" if it's still going. It's certainly niggly that there's no way to exit trial -u without an ugly stracktrace and a nonzero return code. cheers, Chris