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

document implprefix argument? #114

Closed
anthrotype opened this issue Jan 4, 2018 · 5 comments
Closed

document implprefix argument? #114

anthrotype opened this issue Jan 4, 2018 · 5 comments
Assignees
Labels

Comments

@anthrotype
Copy link
Contributor

Hi,
I'm new to the project and I'm considering using pluggy in my own application.
So I started by looking at pluggy's documentation, as well as the way it's being used by pytest.

While looking at the latter, I noticed that the PluginManager can also take a implprefix argument in order to search for matching names in a plugin namespace to be registered as hook implementations.
I also noticed pytest plugins have hooks prefixed with "pytest_", and it doesn't seem necessary to mark implementations with pytest.hookimpl decorator to make them discoverable; the latter is of course required if one wishes to customize the behavior of a hook (by passing options to the decorator like hookwrapper, optionalhook, etc.).

As far as I can see, the main pluggy documentation at http://pluggy.readthedocs.io/en/latest/ only mentions the HookimplMarker decorator as the way to mark a function for detection by a PluginManager's register method.
It's true that implprefix is mentioned in the "Public API" section of the docs, as it's in the PluginManager's docstring. However, maybe it could be featured more prominently in the main section?

Or is this intentional and the decorator approach is the method which should be preferred for detection of hook implementations?

Thank you

@goodboy goodboy self-assigned this Jan 4, 2018
@goodboy
Copy link
Contributor

goodboy commented Jan 4, 2018

Hi @anthrotype glad to hear you're considering pluggy for your project 👍

Or is this intentional and the decorator approach is the method which should be preferred for detection of hook implementations?

Yes you have it. The decorator API is the more mature approach and is preferred. This makes hooks and specs explicit and avoids hard to detect problems for contributor's to your project who aren't aware of the naming implications.

If you look at the pytest code base pretty much all hooks now use the decorator API.

@RonnyPfannschmidt @nicoddemus @hpk42 please chime in if I'm incorrect in any of these assumptions.

@goodboy goodboy closed this as completed Jan 4, 2018
@anthrotype
Copy link
Contributor Author

Thanks for the clarification. “Explicit is better than implicit”!

@nicoddemus
Copy link
Member

If you look at the pytest code base pretty much all hooks now use the decorator API.

Indeed we use them for hook specs, but we don't require the decorator for hook implementations. Pretty much every pytest plugin still relies on the pytest_ prefix naming convention to implement the hooks.

@goodboy
Copy link
Contributor

goodboy commented Jan 4, 2018

but we don't require the decorator for hook implementations

Indeed, I remember that now. @nicoddemus that should be something to change no?

@nicoddemus
Copy link
Member

I suggest for us to move this over to #116.

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

No branches or pull requests

3 participants