Make your tool extensible by 3rd party plugins by provding a pub/sub mechanism for plugin writers
WARNING: I have no idea what I am doing (yet)
pip install pluggy
... uses it?
- pytest (place of origin)
- tox
- devpi (pretty sure, but can't access github atm)
- a few others: https://libraries.io/pypi/pluggy
e.g. why not just subclass stuff
pluggy’s approach is meant to let a designer think carefully about which objects are explicitly needed by an extension writer. This is in contrast to subclass-based extension systems which may expose unnecessary state and behaviour or encourage tight coupling in overlying frameworks.
-- pluggy docs
- creates a namespace that provides hook specifications
- namespace created from module or class namespace
- hookspecs are empty functions defining implementation name and footprint
- hookspec namespace provides decorators to be attached to implementors registering them as callback in a list of implementations
- provides a hook caller calling implementations and collecting result(s)
- Inspection: e.g.
get_plugins() - There are options to influence call order, making it optional or stop executing as soon as one implementations returns a result
- a hook implementation can be marked as hook wrapper to serve as a context manager of all other hook implementations of the same hook
- hooks can be marked as historic for lazy evalution
- blocking registration of plugins is also possible
- hook specifications
tox/hookspecs.py - implements its own hooks, e.g.
tox/config.py:tox_addpotion()
- talk slides - hook based architecture of pytest: http://devork.be/talks/pluggy/pluggy.html