Skip to content
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

Possible to tell which hook answered a call? #485

Open
simonw opened this issue Mar 5, 2024 · 3 comments
Open

Possible to tell which hook answered a call? #485

simonw opened this issue Mar 5, 2024 · 3 comments

Comments

@simonw
Copy link
Contributor

simonw commented Mar 5, 2024

I have some code that looks like this:

        opinions = []
        # Every plugin is consulted for their opinion
        for check in pm.hook.permission_allowed(
            datasette=self,
            actor=actor,
            action=action,
            resource=resource,
        ):
            check = await await_me_maybe(check)
            if check is not None:
                opinions.append(check)

        result = None
        # If any plugin said False it's false - the veto rule
        if any(not r for r in opinions):
            result = False
        elif any(r for r in opinions):
            # Otherwise, if any plugin said True it's true
            result = True

This is for a plugin-based permission model.

For easier debugging of complex situations (where more than one plugin might have contributed an opinion) I'd like to be able to tell which plugin returned which values.

Is there a way I can do this with Pluggy? If not, could I request it as a feature?

@RonnyPfannschmidt
Copy link
Member

The details are not passed back, however hook tracing should be able to help debug

@pirate
Copy link

pirate commented Sep 27, 2024

I also need this ability for similar reasons, I'm using plugins to implement a lot of extractors that consume URLs and produce various outputs.

It would be very helpful to see which extractor plugin produced a given output, without having to include it manually in every response.

This would be possible if there were a function available like:
PluginManager.get_hookimpl(plugin_name, hook_name, fallback)

Then you could prepare a dict of {plugin: handler} ahead of time, and then call each handler manually:

url = 'https://example.com'
hook_to_call = 'extract_url'

handlers_by_plugin = {
    plugin_name: pm.get_hookimpl(plugin, hook_to_call, None)
    for plugin_name in pm.get_plugins()
}
results_by_plugin = {
    plugin_name: handler(url)
    for plugin_name, handler in handlers_by_plugin.items()
    if handler is not None
}

Can I submit a PR to add HookCaller.get_hookimpl to the PluginManager? (with the difference being that it accepts a plugin ID + hook name as args)

This could kill two birds with one stone and provide a way to control call ordering at runtime too: #250 (comment)

# example of customizing call order using handlers_by_plugin from above

preferred_order = ['wget', 'singlefile', 'dom']

results = {}
# process ones with a defined order first
for plugin in preferred_order:
    results[plugin] = handlers_by_plugin.pop(plugin)(url)

# then process all other handlers
for plugin in handlers_by_plugin.values():
    results[plugin] = handlers_by_plugin.pop(plugin)(url)

Alternatively this could also be another proxied HookCaller like #250 (comment) that responded with a dict of {'pluginname': response, 'pluginname2': response, ...}. (like PluginManager.subset_hook_caller())

@RonnyPfannschmidt
Copy link
Member

i strongly want to avoid adding a way to return the plugin in a normal way - as from the design standpoint needing the plugin to be returned to do something sensible means the hook is not engineered correctly

i want to reduce the ways one can call/interpret hooks as historic hooks already create quite a problem in terms of structures (i need to take some time to write down a design document for a replacment for historic hooks)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants