-
Notifications
You must be signed in to change notification settings - Fork 25
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
why env has a higher priority than command line arguments? #28
Comments
usually ENV is the last step for overrides since apps, after already internally configured, are deployed in different environments. only those ENV variables that match will end up overriding the final config, all other variables won't be used by default unless you force them to be used by in most cases (load-config :merge [(parse-runtime-args ...)]) In case you have no control over the ENV, but still want to override them as the last step, you can always do: export DB__URL=foo; ./run-your-program when you run your built, deployed artifact in the particular environment. |
I cannot agree on this; command line args should always have the highest precedence, as in most softwares, for example: https://docs.aws.amazon.com/cli/latest/topic/config-vars.html#precedence Nevertheless, thanks for the trick |
aws example is first and foremost has to do with while thinking about it some more, I still believe there should be an existing merge order with ENV being the last layer, but I do agree that there has to be a way to override any layers with "that last" custom map. I added an This is in |
yup. thanks for your quick response. https://github.com/luminus-framework/guestbook/blob/master/src/clj/guestbook/core.clj#L22 |
yep, I do agree having an option to override defaults is a good idea. Let me know whether |
override-with is fine. |
For example here:
https://github.com/tolitius/cprop#merging-with-all-system-and-env
The text was updated successfully, but these errors were encountered: