Closed maruks closed 8 years ago
Might make sense to use a different configuration library such as cprop. Would you mind trying it out with it to see if it works better in your case?
Environ works just fine if only strings are used as configuration values. I changed boolean true to string "true". There is some code in reagent template that needs to be changed as well. It expects boolean to be returned from env function.
Right, I'm not sure I agree with the decision environ makes to require environment variables to be strings. The cprop library is more flexible in that regard.
I've updated to use my config lib that's based on environ. It works similarly enough to make transition seamless, but isn't opinionated about the input types. Should address the issue.
I think it makes sense to have string only config values.
Java properties and env variables cannot be of any other type.
What if you want to override a boolean config value?
I think it makes more sense that you have to parse the data coming in from the environment, as opposed to using string values within the application itself. When using shell variables or Java properties, it would be better to do something like:
(def env
(-> config.core/env
(update :port #(Integer/parseInt %))
(update :dev #(Boolean/parseBoolean %))))
It's also worth noting that the config library allows using an EDN based configuration file as well. That way you can supply external configuration that's already structured.
If environ configuration value is not a string then it prints a warning "environ value true has been cast to string"
The message ends up in core.js and causes compilation error https://gist.github.com/darwin/3aeb13d9e3631a4c421d
please fix project.clj