Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
carrot-garden opened this issue Aug 24, 2012 · 9 comments
Closed

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

carrot-garden opened this issue Aug 24, 2012 · 9 comments

Comments

@carrot-garden
Copy link

the bible says:

https://github.com/typesafehub/config/blob/master/HOCON.md#include-syntax

"Value concatenation is NOT performed on the "argument" to include or url() etc. The argument must be a single quoted string. No substitutions are allowed, and the argument may not be an unquoted string or any other kind of value."

then what is the solution for this requirement:

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

@carrot-garden
Copy link
Author

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

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

this feels very wrong :-)

@havocp
Copy link
Collaborator

havocp commented Aug 24, 2012

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.

@carrot-garden
Copy link
Author

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
Copy link

velvia commented Nov 13, 2012

+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
Copy link
Collaborator

havocp commented Nov 13, 2012

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
Copy link

velvia commented Nov 14, 2012

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
Copy link
Collaborator

havocp commented Nov 14, 2012

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
Copy link

lygaret commented Feb 20, 2013

+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
Copy link
Collaborator

havocp commented Mar 7, 2015

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

@havocp havocp closed this as completed Mar 7, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants