Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This has been nagging me for a while, even if the impact is likely only minor, and only on a single configuration.
pytestallows fixtures to be reused across tests, by providing them with ascope. Thescope=sessionwould spin up the fixture on the first use, and shut it down only once the last test using it has completed. The problem is that withpytest-xdistthe main process just enumerates tests and spawns workers, each in their own process. This also means that each fixture with scope session is also multiplied by the number of workers, because the workers cannot share fixtures among each other, living in different processes.This plugin implements a global fixture, even when spawning and executing tests in workers. It does so by making the fixture negotiation an explicit step, and the coordinator (main process) is in charge of actually starting / managing / stopping fixtures.
We spawn a small RPC in the coordinator, and inherit the details to contact the RPC to the workers. The workers can then talk to the coordinator, ask for a fixture, and they get a configuration back from the shared fixture (usually just a DSN or other connection string to interact with the fixture).
This is used in our case, for
postgreswhich we used to spawn a new instance of for each test, but since it has a way to serve multiple tenants, via separate schemas and databases, the global fixture just adds dbs and returns connection strings, and on free, the coordinator drops the fixture again.It may only be sporadically used in CLN, but I found this incredibly useful in more advanced setups, where DB servers and Message Queues, etc must be added to the tests.