[Poll]: Configuration of corobo

[nvzard]

Since corobo lives inside a Docker container and is deployed after every commit.
To use the configuration templates, we'll need a way to pre-configure the plugins so that bot admins don't have to configure them after every deployment.

In the comment section, are the different proposed option than can be implemented to auto-configure the plugins at the time of deployment.

Please use a ' 👍 ' to vote for the best-suited implementation.

cc @meetmangukiya @gbin @jayvdb

[nvzard]

Option 1

Simple use of environment variables in the configuration templates. Eg:

    def get_configuration_template(self):
        config = {
           'GH_TOKEN': os.getenv('GITHUB_TOKEN'),
           'GL_TOKEN': os.getenv('GITLAB_TOKEN'),
        }
        return config

Downside: Environment variables on windows are hard to set & change.

[nvzard]

Option 2

Using a Mixin to pre-configure the plugins through config.py file. We'll use DEFAULT_CONFIGS in config.py file to hold the configuration dictionaries for the plugins. Eg:

DEFAULT_CONFIG = {
    'LabHub': {
	'GH_TOKEN': os.getenv('GITHUB_TOKEN'),
        'GL_TOKEN': os.getenv('GITLAB_TOKEN'),
        'GH_ORG_NAME': os.getenv('OPENHUB_TOKEN'),
    },
    'WolframAlpha': {
    	'WA_APP_ID': os.getenv('WA_TOKEN')
    }
}

And configuring the plugins before activation

class MyPlugin(BotPlugin, DefaultConfigMixin):
      ...

class DefaultConfigMixin:
    @property
    def _default_config(self) -> Optional[Mapping]:
        if 'DEFAULT_CONFIGS' in self.bot_config and self.name in self.bot_config['DEFAULT_CONFIGS']:
            return self.bot_config['DEFAULT_CONFIGS'][name]

    def __init__(self, bot, name=None) -> None:
        super().__init__(bot, name = name)
        dc = self._default_config
        if dc and not self.config:
            super().configure(dc)

    def get_configuration_template(self) -> Mapping:
        dc = self._default_config
        if dc:
            return dc

If a config is set, it will autoconfigure the plugin from DEFAULT_CONFIGS

[nvzard]

Option 3

@jayvdb 's workaround #380 (comment)

    def get_configuration_template(self):
        config = {
           'CROSSLINK_GITHUB_TOKEN': '',
           'CROSSLINK_GITLAB_TOKEN': '',
           'CROSSLINK_OPENHUB_TOKEN': '',
        }

        for key in config:
            if hasattr(self.bot_config, key):
                config[key] = getattr(self.bot_config, key)

        return config

    def _get_config(self, key):
        if self.config and key in self.config:
            return self.config[key]
        return getattr(self.bot_config, key, None)

We could put something similar into a super class for all our plugins.

[nvzard]

Option 4

By storing the configuration dictionary in a seperate file default_configs.py which can be mounted to the docker container using docker volumes. The content of the file would be the configurations for the plugins. Eg:

CONFIG = {'configs': {'LabHub': {'TOKEN': 'abc123'}, 'WolframAlpha': {'TOKEN2': 'abc123'}}}

Using a pythin script from inside the container we can import CONFIG from default_configs.py and configure the bot before it is deployed by executing Errbot's Provisioning command

errbot --storage-set core <CONFIG>

and then deploy the bot after it is configured.

[nvzard]

Option 5

By keeping the data/ dir outside the docker container and mounting it instead, we can take advantage of Errbot's storage.

We'd have to set BOT_DATA_DIR in config.py to the path of the mounted data dir.

Currently BOT_DATA_DIR = os.path.join(BOT_ROOT, 'data') where BOT_ROOT is the absolute path of the project root.

[meetmangukiya]

data/ directory is just errbot's shelf storage, it can not even be existing if we use another database, redis, postgres, etc.

[yukiisbored]

Do not consider / assume that this thing will be running inside Docker. If the goal is to have the project reusable outside of coala, don't make decision that could make it unusable for people outside of coala (exp. Not using Docker, Not using Linux, etc).

I believe using environment variables to configure should be considered a cheap hack in comparison to a proper setup. I would prefer if it uses something like Python's built-in ConfigParser and just read it from there. Environment variables can be used to generate the file at the start or have an option to always update it.

I suggest adding command line arguments for --config-file and --data-dir to make it easier to declare where those directories are located.

If it isn't declared try the following in order:

• For the config file:

  1. $(pwd)/corobo.ini
  2. $XDG_CONFIG_HOME/corobo/config.ini
  3. $HOME/.corobo/config.ini
  4. /etc/corobo/config.ini
  5. /etc/corobo.ini

• For the data directory:

  1. $(pwd)/data
  2. $XDG_DATA_HOME/corobo
     3 $HOME/.corobo/data

First, check if there's an exisiting config file and data directory
Second, if they don't exist, use the first one on the list
Third, if it fails (because of permission issue, etc), Fail and print config file and data directory does not exist and corobo cannot make them. Please declare --config-file and --data-dir if you're planning to use a different location. See --help for more details

[jayvdb]

fwiw, the runtime config was finished in #597