Abstract from the typesafe config backend

pureconfig started as layer on top of the typesafe config library. The idea was to keep intact the parsing of files and the resolution rules while adding a generic derivation system that converts a ConfigValue to a value of an arbitrary type. The initial idea was to not tie the library to typesafe config and in future releases to allow to plug in other backends. I would like to start a discussion about this and eventually implement this abstraction in our codebase. My thoughts about this:

1. abstraction: right now the structure that represents a raw configuration is ConfigValue. ConfigValue represents JSON-like values with support for boolean, list, null, number, object and string. If we decide to abstract from the backend, using typesafe structures makes no sense because we don’t want to have typesafe config as dependency when it’s not required. What I propose it to create our own representation of a JSON-like value and keep it as small and minimalistic as possible. For each backend, a new adapter from the backend specific structure to our representation should be coded and that’s the only required piece of code to make the new backend work with pureconfig. I am open to use an external library to represent a configuration if there is a good reason for it.

2. loading: there are multiple ways to load a backend implementation at runtime. In Java it is common to set the implementor class somehow, e.g. via configuration files, and then use the class loader to load the specified class. This style allows to create a new backend without recompiling pureconfig but has the side-effect that there are no checks at compile time. I personally don’t like this style even if I understand the great flexibility it provides. I like to have my compiler to link all the pieces together before I use the library. Consequently I propose to make the core of pureconfig abstract from the implementation and then have one subproject for each backend. If a user wants to implement a new backend, he/she just have to add a new subproject with minimum effort. Each backend would have its own artifact on maven.

Let me know what you think about these two points and if you want to add other points to the discussion. I would prefer to have a clear idea on which everybody agree before we implement it.

[ekrich]

You could also consider supporting sconfig as a way of potentially supporting Scala.js and Scala Native. https://github.com/ekrich/sconfig/

[mberndt123]

Right, so all of the stuff you describe seems to be HOCON-specific, which means that abstracting from HOCON would sort of defeat the purpose of the library, right?