A modern programming language that makes developers happier.

kotlinlang

Specifically <https://github.com/lightbend/config#uses-of-substitutions>

That still makes it difficult to apply <https://12factor.net/config>, since for each env var, I need to create in HOCON and use `${...}` to make a placeholder for the env var... It would be nice to have every env var with a certain prefix to work similarly to java system props in that lib... like in my example code. 

Then I would just use HOCON for defaults that are included in the Docker image and doesn't change on my staging or production branches in my CI/CD. But in my Docker Swarm service definition, I would override any of the necessary values w/ corresponding env vars...

Btw, did you make the `ApplicationConfig` interface and all as a wrapper for the lib because you might replace or add features to it? It seems like the lib itself is pretty powerful as is, it's just a pity it's missing this feature...

Yes, we were not sure about underlying config implementation, so made a small abstraction. It is not very good, but we don’t have anything much better. What we are working on is <#C7A1U5PTM|serialization> based configuration, so you don’t need an API at all, just something like `config.get&lt;MyConfigurationClass&gt;()`.

That's very nice! But how would that support env. vars.? Or is there no plan for that?

Env vars expansion will still be needed to be done in the underlying engine, like HOCON. Since configs are layered in HOCON, I think we can make a special env layer…

There's currently such a serialization lib (Kotlin extension to HOCON) btw: <https://github.com/config4k/config4k>

But I’m not sure it’s really that hard to add placeholders, which also will document what env vars are used.

Yeah, I have an old branch with config4k, there were some issues at that moment, may be need to re check it. But then, we have serialization almost working too.

The documenting is in the `Dockerfile` with the `ENV`s, and it'll be two lines in HOCON, one for the default, and one for the override w/ env var...

May be we can contribute something like `${?FORCED_BASEDIR : "default"}` to HOCON? :slightly_smiling_face:

That might be a bit better :slightly_smiling_face:, but it's funny why they implement this for java's System props and not for env. vars? I guess it goes back to the pre-Docker days that you run a whole Linux for more than one thing... w/ Docker the whole Linux instance is for the service.