-
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
same file overrides #10
Comments
definitely interesting... :) I usually use different files for different environments, and
Thanks for the idea. |
The 2 problems I have with storing config across multiple files:
This is why I like the idea of having config in one place, as much as possible; if that is the end goal then you can't do much better than 2. I do, however, realise that by conflating all environments into a single file we lose some flexibility: It's not as easy to just deploy the application with its intended environment; it contains all other environments as well. Since any sensitive config ought to be set through environment variables – and cprop makes this a trivial exercise –, I'm not sure how much of a concern this is, but there may be other reasons why it's a bad idea! I think 1 also has this issue. There might be some experimentation to be had around adding per-key overrides. Something like this perhaps:
I'd be interested to hear your thoughts :) |
is what feels off. so does I think this should work though: (cprop/load-config :resource "config.edn"
:merge [(from-resource "config.env")]) where or (cprop/load-config :resource "config.edn"
:merge [(get-in (from-resource "config.env") [:environments "prod"] {})]) in case you'd like to have a single Let me know what you think about this approach. |
I think either of those suggestions is sufficient, with a slight preference towards the latter since it's easier to get a bird's-eye view of all the environment overrides. If you were worried about shipping the application with redundant environment config then the first is preferred. Incidentally, I came across this recent blog post: https://juxt.pro/blog/posts/aero.html After reading I'm still unsure about whether keeping overrides in the same file is actually a bad idea or not. And turns out I was completely unaware of the potential security issues of storing passwords and secrets in env vars! |
While trying to make configuration explicit Aero introduces an implicit DSL ( Keeping values for all environments in the same file might have to do with taste, but I don't really like it:
I do get the point about
|
Yeah Aero's reader macros do seem like overkill, and after some reading around (thanks for the SO link) I don't think the case against environment variables is a good one. I take the point that some organisations would find keeping prod config alongside dev/qa restrictive – a strong enough reason to promote the use of separate env files. "in case ENV variables is not a preferred approach, just pull the values from Consul / etcd / Zookeeper." I'm not so keen on this. If we pull config from another service that the app depends on in order to start, then that introduces a dependency on that service and the (admittedly quite unlikely) potential situation of being unable to deploy anything. DNS failures can also cause problems here. Back to the main point. I don't think any code change is required here, but I would find some guidance in the readme about environment overrides useful. Thanks for your input :) |
sure, thank you. great discussion! :) |
Just like Nomad: https://github.com/jarohen/nomad#grouping-hosts-together---environments-041
I like this feature a lot because it means I don't have to spread my config around unnecessarily. At the moment I work around this by doing:
But of course
defaults.edn
gets read and parsed twice. Not the end of the world sinceload-config
is only called once anyway, but would be nice to have this feature supported if possible.Cheers!
The text was updated successfully, but these errors were encountered: