Feature idea: Use pydantic for loading configuration

[davidolrik]

Today Slack Machine uses a plain python file for its config, which I find less than ideal.

I would like to put my bot in git, but I don't want to commit any secrets into git.

To solve this I tried to do a simple import of the yaml module in local_settings.py, and load my secrets from there, but this won't work when using Redis as storage backend.

The reason it won't work is that the config is pickled and put into the storage, so any object will yield the error message seen in issue #273.

Changing to Dynaconf provides the benefit of letting me store my secrets separately from the main config.
It will also provide a lot of other benefits and features that Dynaconf provides, like letting me choose which format I want to store my config in, multiple environments etc.

What do you think?

[DonDebonair]

I'm not 100% convinced to be honest. I strongly believe in the 12-factor app guidelines, which is why you can configure Slack Machine using environment variables. This allows you to keep secrets out the local_settings.py. The reason why I still like the idea of configuration inside a Python file, is because it's programmable and allows for more complex data structures, should plugins need it.
Another thing to think of is that - while Slack Machine hasn't reached v1.0 yet, which technically means I could break backwards compatibility - quite a lot of people are already using SM, which would create quite an issue if I were to switch to something like Dynaconf. I don't see how I could do that now without breaking backwards compatability with people's SM installs.
Lastly, while the idea of Dynaconf is nice, it doesn't seem super easy nor intuitive. So it would introduce some complexity into SM. I'm hesitant to do that.

In short, I'm not against it up front, but I'd need some more convincing and alleviation of the aforementioned problems before I would accept a PR to do what you propose and/or work on it myself.

But I like that you're looking for ways to improve SM! Your input is much appreciated!

I will read up some more on Dynaconf in the coming week.

[davidolrik]

Dynaconf has support for multiple formats, so we could do python config called local_settings.py and keep everything working as it is now - even though I don't like config in code.

Dynaconf can also be configured via environment variables, but also via a ton of other different ways - e.g. Vault for secrets, .env, .secrets etc.

The feature I like the most about Dynaconf, is different environments, which keeps me from shuffling config variables when testing vs when deploying.

But checkout the docs to Dynaconf, it's really nice and can be customised into a perfect fit for Slack Machine.

[DonDebonair]

I will look into it this week and get back to you about this.

[davidolrik]

In the mean time I have fallen completely in love with pydantic which solves more than than just the config loading - It could also replace dacite and add more strict type checking where ever it is needed.

On the config side pydantic also has support for secrets which would make deploying slack-machine to Kubernetes really easy.

[DonDebonair]

Might indeed be useful. I dropped you an email to discuss Slack Machine in a more general sense.

[DonDebonair]

Hey @davidolrik, I don't know if you're still using Slack Machine, but I'm working on it again. My first order of business is making it use asyncio (and in the process, generally refactoring it).

Configuration is another important topic I'd like to tackle soon. I've been reading over this issue again, and I wonder what the best approach is. I think Dynaconf and Pydantic are both valid options. I wonder if we'd use Pydantic, how we would deal with new settings required by plugins. Pydantic models are static, so the only think I can think of is to add a sort of "catch-all" dict setting on the Settings model. Do you have another idea?

If you moved past using Slack Machine, I also totally understand and won't bother you again!