the docker composition docker/devel.yml has been adapted to the refactored plugin framework with search and retrieve plugin dependencies.
the docker composition docker/env.yml has been added. Very similar to docker/devel.yml, it provides all services needed for running a lookup server, but without the lookup server itself. This is useful for local testing, where one might want to run the lookup server outside of a container for quick stitching together and reconfiguration of search, retrieve and other extension plugins.
Script snippets in folder devel break down what's otherwise happening in the docker/devel.yml composition's lookup server container's docker/dtool_lookup_server_devel/boot.sh for the same purpose, namely running an easily reconfigurable lookup server directly.
Importantly, I have moved the the loading of entry points and the instantiation of plugins from the dtool_lookup_server/__init__.py module-wide scope to the app factory and refactored all access to these plugins by using current_app (https://flask.palletsprojects.com/en/2.3.x/api/#flask.current_app) imported from the flask modules. This modification is necessary because plugins and their tests will fail due to circular imports whenever they import utility functions from the core dtool_lookup_server, e.g. something from dtool_lookup_server.utils. Besides that, it's probably cleaner this way anyway, having one plugin instance per app instance.
This PR sums up a few atomic earlier PRs, namely,
Next to this,
docker/devel.ymlhas been adapted to the refactored plugin framework with search and retrieve plugin dependencies.docker/env.ymlhas been added. Very similar todocker/devel.yml, it provides all services needed for running a lookup server, but without the lookup server itself. This is useful for local testing, where one might want to run the lookup server outside of a container for quick stitching together and reconfiguration of search, retrieve and other extension plugins.develbreak down what's otherwise happening in thedocker/devel.ymlcomposition's lookup server container'sdocker/dtool_lookup_server_devel/boot.shfor the same purpose, namely running an easily reconfigurable lookup server directly.Importantly, I have moved the the loading of entry points and the instantiation of plugins from the
dtool_lookup_server/__init__.pymodule-wide scope to the app factory and refactored all access to these plugins by usingcurrent_app(https://flask.palletsprojects.com/en/2.3.x/api/#flask.current_app) imported from theflaskmodules. This modification is necessary because plugins and their tests will fail due to circular imports whenever they import utility functions from the coredtool_lookup_server, e.g. something fromdtool_lookup_server.utils. Besides that, it's probably cleaner this way anyway, having one plugin instance per app instance.