Consider using pluggy for plugin management

[lemon24]

https://pluggy.readthedocs.io/

Pros:

• widely used (pytest, tox, datasette)
• standardization
• validation (all hooks have specs, argument names)
• opt-in arguments, deprecations (API evolution)
• discovery (via setuptools entry points)
• plugin management (plugin == named connection of hooks)
• some exception handling
• debugging support
• already documented

Cons:

• extra dependency
• widely used => harder to contribute to (Great care must taken when hacking on pluggy since multiple mature projects rely on it.)
• update-style hooks where we continue to run after failure may be fiddly to implement
• requests wrapper style hooks where the return value from a plugin is passed to the next plugin might be fiddly to implement
• LIFO order
• how would lazy plugin loading work?

[lemon24]

I had another look at pluggy, and confirm the pros still stand.

However, the following two cons remain:

• update-style hooks where we continue to run after failure may be fiddly to implement
• requests wrapper style hooks where the return value from a plugin is passed to the next plugin might be fiddly to implement

As far as I can see, the calling logic is buried deep within the codebase, so it likely can't be / isn't meant to be changed.

There's also pytest-dev/pluggy#419 says collecting exceptions is out of scope, but it also mentioned further down that it may be solved in pytest-dev/pluggy#321; it may be worth describing the reader usage patterns in that issue?

[lemon24]

Added pytest-dev/pluggy#151 (comment) describing the current use cases, and also how one may work around the current pluggy model to implement them.

even if using pluggy would require some work-arounds for calling, I think the collection / discovery functionality is still more than worth it

I'd say long-term and/or if reader becomes really popular, pluggy is definitely the way to go, but for now I'll close this as YAGNI (yet).