Improvements before bill-teams

[mhxion]

The PR brings a number of new changes, including a few important changes for bill-teams milestone.

Support for new sub-endpoints

Endpoint endpoint /users/{id}/uploads is added. Fixes #131.

plugins configuration field for plugin-specific settings

Plugins can now define their own settings via elapi.yml. This was loosely possible before, but not acknowledged by elAPI itself. Now, elAPI provides a slightly more convenient method for reading plugin-specific configurations for developers.

# elapi.yml
host: https://demo.elabftw.net/api/v2/
api_token: <api key>
plugins:
    bill-teams:
        meta-source: <path to metadata CSV file>  # Not actually read by bill-teams atm, just as an example

We can get all plugins configuration from get_active_plugin_configs:

>>> from elapi.configuration import get_active_plugin_configs
>>> bill_teams_plugin_config = get_active_plugin_configs().get("bill-teams")
>>> bill_teams_plugin_config
{'meta-source': '<path to metadata CSV file>'}

1. Plugin configuration value must be YAML dictionary

This simplifies the implementation and the compliments our unique plugin name enforcement.

# elapi.yml
plugins:
    plugin-a:
        key: value  # Valid
    plugin-b:
        - key: value  # Invalid: not a dictionary but a list

In case of invalid plugin configuration, elAPI will show warning rather aggressively to ensure users are aware as this is as soon as possible, i.e., logs will be shown on the "Message panel" and after any command (except special commands like elapi version, elapi show-config, etc. ofc).

$ elapi get info
WARNING  Configuration value for plugin 'plugin-b' exists in 'elapi.yml' under 'plugins', but it's not a YAML dictionary. Plugin   elapi.py:109
         configuration for 'plugin-b' will be ignored.
<Response>

2. --OC can seamlessly override plugin configurations

Values only targeting a specific plugin or passing a specific key-value pair is also possible with --OC.

# elapi.yml
plugins:
    plugin-a:
        key-a1: value-a1
        key-a2: value-a2
    plugin-b:
        key-b1: value-b1
        key-b2: value-b2

$ elapi --OC '{"plugins": {"plugin-b": {"key-b2": "new-value"}}}'
<Will override key-b2: value-b2 of plugin-b. All other already-existing values will remain in place.>

Improved support for third-party plugins

Fixes #134. This fix almost ensures that any sufficiently complex plugin like bill-work will work without issues as a third-party plugin. Previously, many edge cases regarding loading a third-party plugin were not tested. A new optional project_dir key for elapi_plugin_metadata.yml is introduced. Without project_dir it is impossible for elAPI to tell what the root path is of a third-party plugin project. elAPI, while loading the plugin, will add project_dir to PATH.

# elapi_plugin_metadata.yml
name: frontend
cli_script: ~/Workshop/awesome_elapi_plugin/src/awesome/elapi_plugin/cli.py  # Notice, cli.py is multiple directories deep within from the project_dir
venv_dir: ~/Workshop/awesome_elapi_plugin/.venv
project_dir: ~/Workshop/awesome_elapi_plugin/

Disable --OC for development_mode

development_mode in elapi.yml has proven to be useful in many instances so far. We started off developer_mode with a simple use-case about plugins. Turning development_mode on signals elAPI to allow certain errors to pass without doing any error handling that are normally done for sake of user-friendliness, which a developer might find useful. Essentially, this key changes the "state" of elAPI. It seems, --OC can not really affect development_mode, mainly because development_mode from elapi.yml has to be read first before the state of elAPI can be changed. Once the state has been changed, only then --OC is applied, but then state has already been changed. More concretely, if developer_mode is false in elapi.yml, and a --OC '{"developer_mode": true}' is passed, the value false from elapi.yml is already applied as soon as it is read and the state changes accordingly, so even after --OC overrides developer_mode to true, the state cannot be changed back.

If we still insist on keeping support for overriding development_mode via --OC, we would have to rewrite how --OC parses and applies the values in the first place, which is probably something to look into later.

Other small improvements and bug fixes

Fixes #133, #135. Some other bugs and small improvements were made along the way.

• get_active_host_url_without_api_suffix from elapi.configurations will return the host URL without the api/v2 part
• Better configuration validation (reinitiate_config) during startup
• A few refactorings

[mhxion]

Thanks for approving.