Closed jotelha closed 11 months ago
Began in https://github.com/jic-dtool/dtool-lookup-server/pull/41.
Right now, there is no single global config.
Instead, the /config/info
route tries to import ...config.Config
objects from plugins and nest them within the serialized configuration response like this,
...
"dtool_lookup_server_notification_plugin": "cannot import name 'mongo' from 'dtool_lookup_server' (/src/dtool-lookup-server/dtool_lookup_server/__init__.py)",
"dtool_lookup_server_plugin_scaffolding": {
"some_public_plugin_specific_setting": "public",
"version": "0.1.5.dev4"
},
"jsonify_prettyprint_regular": true,
"jwt_algorithm": "RS256",
"jwt_header_name": "Authorization",
"jwt_header_type": "Bearer",
...
"sqlalchemy_track_modifications": false,
"version": "0.17.2"
One purpose of the current config response was to provide clients with information on the available server side plugins and their versions.
Now, do we want to recommend all plugins to rather use the global flask config with all parameters (core and plugins) in a flat key-value manner instead? Not sure, tending to yes.
Would the /config/info
route then provide only this flat configuration, with a few secret exclusions removed? Not sure, tending to yes.
That would introduce the need for another way of providing plugin and version information via REST API.
One possibility would be via an additional route /config/versions
that lists them in a similar way as done for the dtool CLI at https://github.com/jic-dtool/dtool-cli/blob/58233c23cacbd1f531b7c9fde15309d92bcb7b44/dtool_cli/cli.py#L89-L107
https://github.com/jic-dtool/dtool-lookup-server/pull/41 implements what I suggested here.
A downside to that approach is that plugins have no control over which config values are dumped an which not as soon as they provide them to the central flask config.
Addressed and merged with https://github.com/jic-dtool/dtool-lookup-server/pull/47
Think about how to best implement this