Configuration style

[Airbag65]

We'll at some point need to implement some sort of configuration system, but there needs to be some form of discussion about what type and language should be used. This discussion thread is more or less a continuation of the thread in #15

All input/thoughts/opinions are very welcome :) I am myself willing to do the actual implementing of the system when there is a consensus about how it should be done, but if anyone else feels eager and really want to do it, I will not get in your way!

[mattsva]

I still think that a dynamic configuration would make sense for some specific use cases. There are probably also cases where something like a dynamic integration would just add unnecessary overhead. Because of that, I think we should give the end user the option to choose between a static and a dynamic configuration.
For static configuration, I would use .json in some cases and .env in others. For example, settings such as whether the configuration itself should be dynamic or static could make sense in an .env file.
For dynamic configuration, I would go with Python. Since the project already uses Python, it seems like a natural choice here.
I also wouldn't say that a dynamic Python configuration necessarily introduces that much overhead if implemented the right way. Interpreting JSON also introduces some overhead, after all. I think it would be worth testing both approaches rather than deciding upfront which one is better. JSON is probably the obvious choice for static configuration, but I don't think we necessarily need to limit ourselves to it. Giving the user the possibility to choose between both approaches could make sense depending on their use case.

I'm also willing to help implement such a dynamic/static configuration system. Maybe it's a bit early to introduce something like this, since we don't have that much to configure yet. On the other hand, that might actually make this the right time to do it: with a relatively small configuration surface, the system should be easier to implement and could then grow alongside the rest of the project in a clean way.

Let me know what you guys think ;)

[Airbag65]

Request for some input

If the config-file does not follow the scheme of the config object, i.e. it has more fields than the config does support, should it then:

• simply be ignored and the parsing will succeed?
• exit the execution with a MalformedConfigurationException (for example)?
• return a fallback?
• some entirely different behavior?

@mattsva @danieldeer

[Airbag65]

@mattsva Good timing with my message I guess. I could post a draft PR if you'd like so you are able to pitch in 😄

[mattsva]

Request for some input

If the config-file does not follow the scheme of the config object, i.e. it has more fields than the config does support, should it then:

* simply be ignored and the parsing will succeed?

* exit the execution with a `MalformedConfigurationException` (for example)?

* return a fallback?

* some entirely different behavior?

@mattsva @danieldeer

I would like it to give some kind of MalformedConfigurationExceptionWarning-Warning, but still trys to execute.
-> I would simple ignore what is not defined, but still saying that in a Warning.

Btw we need some kind of startup CLI that could give the user warings, errors etc.
But thats something for later ig.

[mattsva]

@mattsva Good timing with my message I guess. I could post a draft PR if you'd like so you are able to pitch in 😄

We could do that or we could go to another repo, as example your or my fork, and then work there, till we do have something stable and then make a PR. You decide, I mean it doesn't really matter that much where we do that. XD

[Airbag65]

@mattsva Good timing with my message I guess. I could post a draft PR if you'd like so you are able to pitch in 😄

We could do that or we could go to another repo, as example your or my fork, and then work there, till we do have something stable and then make a PR. You decide, I mean it doesn't really matter that much where we do that. XD

I've now made a working implementation of the static version at least. I'll add a draft PR for it. I welcome all input you can give me!

[Airbag65]

This message comes pretty late but the PR is no longer a draft and. As of now i have only made the static configuration, but it works rather well. If you want to @mattsva you are free to tackle the dynamic one (it seemed like you kinda wanted to 😃). Otherwise I could get on that too.

And also a more general question: Should I make an issue for it and link it? It might seem a little overkill but I am all for having a set structure to follow when it comes to these things.