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

Consider using pluggy for plugin management #329

Open
lemon24 opened this issue Dec 2, 2023 · 1 comment
Open

Consider using pluggy for plugin management #329

lemon24 opened this issue Dec 2, 2023 · 1 comment

Comments

@lemon24
Copy link
Owner

lemon24 commented Dec 2, 2023

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
Copy link
Owner Author

lemon24 commented Oct 1, 2024

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?

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

No branches or pull requests

1 participant