-
Notifications
You must be signed in to change notification settings - Fork 41
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
Plugin architecture #12
Comments
In the current architecture these could simply be separate backends. Backends can register themselves using |
I have two systems where plugins are needed. One of them has a few mechanisms for plugins. This project is passing through an update, starting by getting a We are thinking about using simple entry points (other good doc from setuptools). I believe PyTest and PyLint use this approach. Scrapy is a different beast, so they used a different approach to allow scrappers to easily extend scrapy, without the need to package a python utility with setuptools. |
We could support plugins for pre- and/or post-processing the document analysis functionality.
A plugin could be a subclass of a class like this:
For registering plugins, we could perhaps make use of PluginBase. Each plugin would be a separate Python project that registers itself to the Annif plugin system. Each Annif project could define a set of plugins to use. The plugins could be stacked/chained, so that the result of one plugin would be fed to the next one in the chain.
Plugins would be fed the raw result of Annif queries (with lots of candidate subject), before cutting down them into the requested size and/or applying score thresholds. This way the plugins have more candidate subjects to work with.
Ideas for plugins:
The text was updated successfully, but these errors were encountered: