include file("${user.home}/.service/secret.properties") ? about config

my current work around is custom url hander with extra parser:

include url("config:/${user.home}/.service/secret.properties")

this feels very wrong :-)

[havocp]

you have to write code to do that right now (though you could just parse a global and per user file directly instead of using includes, then merge with withFallback)

one issue is that currently all includes are loaded and then substitutions are resolved. so user.home may be defined inside the included file. supporting substitutions in includes would require an earlier resolve phase or something.

Another issue would be escaping (to expand user.home into a file URL it needs to be escaped; and differently depending on whether it's a query parameter or in the path or hostname I believe).

so the spec punts on this because the issues seem tricky and error-prone.

thanks for getting back;

re: "you have to write code to do that right now" - as you can see from all my issues here, I am trying to push back into typesafe.config as much as possible :-)

re: "so the spec punts on this because the issues seem tricky and error-prone" - would it be possible instead to permit some obvious default behavior and then scare people to death with log warnings or with documentation, instead of just denying this feature outright?

[velvia]

+1. This would be a great feature to have.

@havocp - personally I don't need to have ${user.home} substituted in the included file. I would just want, for example, environmental or system properties substitution in order to have flexibility with regard to included file. For example,

include "${STAGE}.conf"

where STAGE is an environment var for staging, production, test, or different environment-based settings. Then, deploys become super easy.

[havocp]

Another idea here would be to just have an environment variable equivalent for the config.file etc. system properties, perhaps. So you could set CONFIG_FILE=production.conf or something like that.

I don't deny the utility I just don't quite know how to work out the details. Making ${} mean something different (only env vars) in this context seems a little clunky. I don't see how to ignore the escaping issue, other than something lame like throwing an exception if the env var value contains anything that would need escaping in either URL or filename (on any platform) ... seems that list is long enough that people would encounter the exception in practice.

For the benefit of any bystanders who have not worked it out, the way you would solve this now is change your ConfigFactory.load() to ConfigFactory.load(getenv("STAGE")) and then in production.conf start by doing include "application.conf"

[velvia]

Do you mean something like

include envvar("CONFIG_FILE") ?

That would work, I think.

-Evan

On Tue, Nov 13, 2012 at 12:38 PM, Havoc Pennington <[email protected]

wrote:

Another idea here would be to just have an environment variable equivalent
for the config.file etc. system properties, perhaps. So you could set
CONFIG_FILE=production.conf or something like that.

I don't deny the utility I just don't quite know how to work out the
details. Making ${} mean something different (only env vars) in this
context seems a little clunky. I don't see how to ignore the escaping
issue, other than something lame like throwing an exception if the env var
value contains anything that would need escaping in either URL or filename
(on any platform) ... seems that list is long enough that people would
encounter the exception in practice.

For the benefit of any bystanders who have not worked it out, the way you
would solve this now is change your ConfigFactory.load() to
ConfigFactory.load(getenv("STAGE")) and then in production.conf start by
doing include "application.conf"

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/36#issuecomment-10342537.

Because the people who are crazy enough to think they can change the world,
are the ones who do. -- Steve Jobs

[havocp]

I didn't mean syntax in the file itself, just that right now you can do "java -Dconfig.file=production.conf" and we could also support "CONFIG_FILE=production.conf java"

[lygaret]

+1

This is something I assumed would work, and then when it didn't found the line in the spec. I know this has been dead for a while, but it would be really, really useful to be able to do simple substitution in the include line.

If the goal is to not overload the ${} syntax, could we maybe add a new syntax that's only allowed in include lines,
%{} or something?

[havocp]

This is the same as #122 I think which has more discussion, so I'll close this copy.