Closed ljosa closed 8 years ago
Take a look at: https://github.com/weavejester/environ/issues/16#issuecomment-54326836
Ideally you shouldn't be using env
directly, but as a basis for your configuration.
The distinction between static environment and mutable configuration is well taken. However, much of the appeal of using the static environment is that it makes it unnecessary to pass the values around the app (as arguments, and perhaps using component). Precisely because the environment is static, it's safe to just reach into a global (such as environ.core/env
) and grab the values when needed.
So using the environment simply as initial configuration would indeed "solve" the problem of making it possible to modify values in the repl, but at the cost of having to treat the values as mutable configuration. That's why I would like an override!
function for use in the repl during development, so I have a way of setting the environment without having to restart the JVM and lose my state.
You can still write a global configuration:
(def config
{:port (Integer. (env :port "3000"))})
Even if you want global state in your application, there's no reason it needs to be environ.core/env
in particular.
I was trying to avoid having to do something like this, as I think environ's approach of never modifying the environment is a good design. But having to restart the JVM to make an environment change during development was too much of an inconvenience: it made it too tempting to make a quick change to my code instead, and hack in a literal value in place of the
(:env …)
form. Today, I accidentally committed a change like that, and it made it to production.So I hope you will accept this PR, which provides a less dangerous mechanism. I have tried to make it abundantly clear that it's only for use in the REPL during development, and not for production use.