lightbend / config

configuration library for JVM languages using HOCON files
https://lightbend.github.io/config/
6.11k stars 966 forks source link

FR: keys in substitutions relative to scope #533

Open ghost opened 6 years ago

ghost commented 6 years ago

Hi, love your lib, been using on our project for three years. Only thing that makes configs awkward to work with is when I'm using defaults, like

myapp {
    def.url = "http://127.0.0.1"

    blah1 = ${def.url}"/blah1"
    blah2 = ${def.url}"/blah1"
    blah3 = ${def.url}"/blah1"
}

Specifying def.url relative to myapp doesn't work, have to go with the full path myapp.def.url which makes for a lot of cumbersome copy-paste, especially in real world, large config files with more nested sections.

Would be great if it worked, perhaps expressed as ${.def.url} to distinguish absolute from relative.

Any chance this can be done? Thanks.

mmuschalik commented 6 years ago

Yes! This is also what I'm after. Being able to use a relative path for substitution would help a lot.

hello.conf:

hello {
  msg = 'hello '${../name}
}

app.conf:

hello_david {
  name = "david"
  include "hello.conf"
}

hello_lisa {
  name = "lisa"
  include "hello.conf"
}

Then I'd expect: hello_david.hello.msg = "hello david"

Likewise for Lisa: hello_lisa.hello.msg = "hello lisa"

This enables me to reuse conf files with different substitutions.

havocp commented 6 years ago

I'm open to it. I think the discussion on https://github.com/lightbend/config/issues/40 is about the same issue. It needs thinking through. I do think searching global scope first will be a bit surprising here, and even searching lexical scope second maybe isn't quite backward-compatible. So that would argue perhaps for a different syntax for lexical search as suggested on that other issue. If you agree that #40 is the same we could close this issue to avoid duplication. Thanks!

mmuschalik commented 6 years ago

Yes, I agree the local scope would solve my issue. How about:

Local scope: ${this.name} Global scope: ${name}

So, adopt the Java way of classes, but obviously keep backwards compatibility. this super

Feel free to close this one, I'll repost on issue 40