Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add persistent configuration into Bot #57

Open
archangelic opened this issue Feb 22, 2019 · 4 comments
Open

Add persistent configuration into Bot #57

archangelic opened this issue Feb 22, 2019 · 4 comments
Labels
core issues related to core pinhook functionality such as plugin reloading, internal commands future Things on the roadmap question

Comments

@archangelic
Copy link
Owner

The bot needs persistent storage, but not enough to justify a database (see #51). I believe the solution is to have a config file passed to the Bot object that it can read and write to. This can also help in doing config-only init (#39)

So the only decision i need to make is to standardize the format for config:

  • ini - a little obtuse, don't really care for this option
  • yaml
  • toml
  • json - hard to hand edit

Any thoughts?

@archangelic archangelic added question future Things on the roadmap core issues related to core pinhook functionality such as plugin reloading, internal commands labels Feb 22, 2019
@ixxie
Copy link
Contributor

ixxie commented Feb 24, 2019

Well yaml is becoming increasingly standard for configuration files, which is a good reason to use it.

However, having the bot write to a configuration file seems a bit odd; normally configuration files are immutable, and tracked in a version control system. I have often wondered if it is possible to design a configuration system that simultaniously does both declarative and imperative configuration, but I don't think you would be interested in piloting such techniques with pinhook.

If I am right and this is undesirable, we should distinguish the usecases here:

  • configuring the bot declaratively
  • saving state derived from imperative actions

Assuming you want to stick to one configuration language, you could for example have an immutable config.yaml which is committed to git, and a mutable state.yaml which is not committed to git, where the bot can write various stuff, like banned users.

@archangelic
Copy link
Owner Author

The thing is that config.yaml might have server, or channel passwords associated in it. May not be the best thing to keep in git repos.

Also a possibility is to add a small executable that can both create the config and start a bot based on the configuration file provided.

@ixxie
Copy link
Contributor

ixxie commented Feb 27, 2019

Thats a good point.

One way to deal with this is a secrets.yaml, but this may be annoying to have so many files. One way to do this is to offer the possibility to either have one or multiple yaml files as configuration; in the many case you would deep merge the resulting dicts to produce the full configuration.

Even without version control, I would still not like config.yaml to be mutable by the bot, at least not with banned users as the list can get big.

@archangelic
Copy link
Owner Author

Totally agree at this point that mutable data should not be in the config. Going to continue discussion on that in #51.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core issues related to core pinhook functionality such as plugin reloading, internal commands future Things on the roadmap question
Projects
None yet
Development

No branches or pull requests

2 participants