-
-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Design discussion: support higher-scoped (class/module/session level) fixtures? #89
Comments
Using the same trio loop with different tests is a very slippy slope (typically with the current Adding greenlet to the mix is a whole new layer of complexity, pytest-trio is already far from trivial so this seems like another big red flag. I think the best way to implement higher level fixture is to use them to start a separate trio loop within a thread. |
I was investigating using pytest-trio to write some integration tests, where I have some expensive services to setup, so want to have session scoped fixtures for the services. I also want to collect logs from the services as they run, and sometimes restart those services from the tests. It is definitely less appealing if I need to manage my own loop for anything session scoped, or that interacts with code from the session scoped things. In terms of implementation, it looks like how trio is structured to support guest mode could be used to support suspending and resuming the loop. With the current public API, you could have one long-running trio loop, which is what is exposed to users; then, when running a async test or fixture, iterate the host-loop calls (perhaps using a separate trio loop). This would require at least a little glue to capture the guest calls to It is definitely true that you can't use the current nursery fixture from non-function scoped fixtures; the same is true of pytest's |
I'm unclear on what the danger is in using the same trio loop for both session and module fixtures in addition to just function fixtures. I don't understand why we couldn't have a session-scope nursery, a module-scope nursery under that, then the function-level nursery under that, then automatically cancel the nurseries when the module is complete and at the end of the session, in the same way the function level nursery is already cancelled. Is it somehow possible for an async method to outlive the nursery it was spawned in? |
I'm pretty sure it's possible if we're willing to use greenlet.
Here's a sketch that's missing important details like exception propagation.
Hook pytest_runtest_loop to keep a Trio event loop running in another greenlet for the whole pytest invocation:
Hook fixture setup to run async fixtures in the Trio greenlet:
Hook running-the-test to run async tests in the Trio greenlet (not shown).
The details are decidedly nontrivial, but I don't see any showstoppers... thoughts? Maybe this could totally replace pytest-trio's current strategy, but it's not a win across the board, so I'm imagining it more as an alternative mode.
Benefits:
Drawbacks:
The text was updated successfully, but these errors were encountered: