weavejester / environ

Library for managing environment variables in Clojure
924 stars 71 forks source link

`override!` function for modifying the environment #59

Closed ljosa closed 8 years ago

ljosa commented 8 years ago

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.

weavejester commented 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.

ljosa commented 8 years ago

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.

weavejester commented 8 years ago

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.