-
Notifications
You must be signed in to change notification settings - Fork 22
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
Useful against pollution of interpreter state #8
Comments
feel free to do that, also please note that this plugin is currently unmaintained |
I believe pytest-forked needs to develop some patterns or best practices around it. Most importantly (to me) the |
mypersonal oppinion is that this is better served on top of actual xdist, forked has a number of drawbacks, however xdist is not in a shape to support those details (lack of support for multiprocessing among other things) |
@RonnyPfannschmidt I don't understand what you mean. Why do you both think that xdist would serve #23 better and that it can't serve #23 at the same time? |
@untitaker foked actually forks the interpreter, kills the stdio connection and then at a random later point sends all reports via the stdio fds of the child to the parent xdist on the other hand starts a interpreter, collects tests completely separate, then just runs that test so using xdist machinery would make for better isolation and better execution/reporting however the scheduling mechanisms and the process execution mechanisms in xdist need a feature extension for this use-case to work nicely |
Does xdist run each test in a separate process, or does it fork to create a workerpool? I definetly need one process per boxed test. From my understanding you have collection per-worker in xdist but I don't see how that's beneficial to me here. Right now I cannot use parallelization of xdist for my own purposes anyway because I have certain tests that cannot be run in parallel (because they write to a shared pg) |
what you describe is the current behaviour of xist, |
Just wanted to point that this package can be a useful protection against "pollution" of the interpreter state.
For example when testing behaviour of custom imports, given the global state of
sys
, and the cache mechanisms, having boxed processes prevent unknowingly reusing a module imported from another test.And there might be more cases like this one.
We should probably gather them in one place (
README
?) as they might be a bit esoteric for the newcomer, and it would be useful to pin them down.The text was updated successfully, but these errors were encountered: