-
Notifications
You must be signed in to change notification settings - Fork 123
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
Allow for custom hook callers? #151
Comments
i propose deferring this until we can experiment against trio and asyncio based on initial example i'd absolutely avoid multio |
oh - we might want to investigate removing multi-call by moving it into a hook-caller subclass/mixin |
How about multiple hook callers? At work we might need to use a pluggy hook call system identical to |
Love both of those ideas! |
@nicoddemus sounds like overkill a hook parser or a wrapper sounds more viable there |
It's already possible to define a synchronous hook that internally does async def run_test():
await run_hooks("setup-fixtures")
await run_hooks("run-test")
await run_hooks("teardown-fixtures")
trio.run(run_test) so that multiple hooks are running under the same event loop. In principle I'm guessing this wouldn't be too complicated. But there's not much point unless one of pluggy's users (like pytest) is interested in using it in this mode. |
@njsmith I've toyed with this idea and what I ended coming up with is that hookimpls essentially become coroutine factories and the caller awaits their results, that way you can call from it inside another coroutine without pissing off the event loop (not sure how trio or curio handle the equivalent of I never expanded it beyond toy examples so I'm not sure what shortcomings I missed beyond the caller needs to reimplement some of pluggy's filtering logic. |
i had a sync with @simonw on the weekend and i will try to incooperate the details into pluggy as i sprint on speedups this week |
In #133 there was a request to be able to provide a custom
_HookCaller
(in this case in order to be able to warn on deprecated hook calls - since addressed via #138).This feature may be quite useful in the future not only in its ability to allow users to customize the
pluggy
runtime but also if we want to eventually support async / coroutine based plugins (this can be done loop agnostic these days with something likemultio
and/ortrio-asyncio
).I'd like to get feedback on this.
To start it would mean that we would make a simple change where
PluginManager
can take ahook_caller_type
as input during instantiation.The text was updated successfully, but these errors were encountered: