-
Notifications
You must be signed in to change notification settings - Fork 967
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
Comments
my current work around is custom url hander with extra parser: include url("config:/${user.home}/.service/secret.properties") this feels very wrong :-) |
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? |
+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. |
Another idea here would be to just have an environment variable equivalent for the config.file etc. system properties, perhaps. So you could set I don't deny the utility I just don't quite know how to work out the details. Making For the benefit of any bystanders who have not worked it out, the way you would solve this now is change your |
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]
Because the people who are crazy enough to think they can change the world, |
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" |
+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 |
This is the same as #122 I think which has more discussion, so I'll close this copy. |
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") ?
The text was updated successfully, but these errors were encountered: