Exchange Config Framework

[t-ober]

Since we have had enough issues in the past with our current configuration derivation I think it's time to switch frameworks.

I'm currently considering https://pureconfig.github.io/ as the main option, as it it also reads HOCON files. We should be able to rip out the old framework, add the new one without breaking older configurations that we have used.

Switching to pureconfig also gives us much more flexibility on how we want to use and setup the configuration as well as the option to document the parameters meaning within the classes, allow more flexible converters for specific fields, e.g. DateTime fields and so on.

[sebastian-peter]

Duplicate of #551

[t-ober]

Whoops my bad. Nevertheless I have made some considerable progress on that front that we can discuss 🙂

[sebastian-peter]

This issue is structured into several tasks: researching and deciding on config libraries, conceptualizing the new config structure and finally, implementation.

Research

First of all, we should look at the available libraries and evaluate their pros and cons.

Candidates

• pureconfig
• pkl
• others

Criteria

• How widely adapted is the library? What is the likelihood that it'll be supported in the future?
• What config languages are supported? Preferably supports HOCON or YAML
• How well does it integrate into Scala? (Scala 3 support as well)
• How easy does the development process become; i.e. adding, removing, adapting configuration?
  • How does adapting the validation scripts play into this, i.e. how well connected are configuration definition and validation?
• How easy does the application of configuration become; i.e. when we want to run simulations, how easily can the config be adapted and validated?
  • How does it behave when used in Intellij vs. in console?
• ...

Concept

There has been some work put into the existing structure of the config. It's fine to start with what already exists and adapt where necessary. Some thought should be put into what parts of the config are or can be optional (and can thus be omitted), and what parts have to be defined for every simulation.

Implementation

... should only start once all tasks above have been solved. It is fine though to play around with the library candidates in order to evaluate the criteria above.

[sebastian-peter]

Since @t-ober already did a considerable implementation work with #900, we can skip the research task above for now. The implementation now mainly needs to be adapted to changes in dev. Beyond that, more issues might come up.