Suggestion: Update README's warning section

[rarguelloF]

Hello,

About the section on the README:

WARNING: This isn't the Elixir way.
Elixir has an excellent configuration system and this dotenv implementation has a serious limitation in that it isn't available at compile time. It fits very poorly into a typical deployment setup using exrm or similar. Configuration management should be built around Elixir's existing system, not environment variables.

I would say it's discouraging people from using this library and using environment variables in general while they are the recommended way in 12factor (https://12factor.net/config) and a popular choice for docker-based applications.

Also, about:

Elixir has an excellent configuration system and this dotenv implementation has a serious limitation in that it isn't available at compile time.

Distillery 2.0 has been released and they added options for handling runtime configuration: https://hexdocs.pm/distillery/config/runtime.html

I would like to clarify I'm not saying env variables are the new "Elixir way". I think hardcoding config in different per-environment files might be a suitable choice for some people, but definitely env variables are also used in the elixir community.

Thanks in advance!

[jarednorman]

These are fair points. I chose stronger language because people coming from other languages might reach for this thinking it was the "normal" or "default" way to handle configuration (because it might be in the language they are coming from,) when for many/most applications there are better options.

I'm certainly open to adding some clarification here to make it clearer for people in situations that make more sense to use this.

[tombh]

The warning is a little confusing to me too, because in Phoenix (v1.4.7) the prod.secret.exs file itself relies on ENV variables, indicating to me that even one of Elixir's most prominent projects (and indeed the project mentioned in the warning in the README here) considers ENV vars a best practice. In fact, the aforementioned Phoenix file even has a comment at the top suggesting that using hardcoded secrets is not recommended:

# In this file, we load production configuration and
# secrets from environment variables. You can also
# hardcode secrets, although such is generally not
# recommended and you have to remember to add this
# file to your .gitignore.

So there's conflicting information.

On balance I'm still inclined to think that ENV is the best place for all sensitive credentials. The essential point for me is the separation of concerns that ENV, and thus dotenv, provide. Phoenix's prod.secrets.exs contains logic and calls to ENV, so it is not the best place to actually put secrets if you want to share that file with collaborators.

The only thing I'm not sure on is the ramifications of "this implementation not being available at compile time". I don't see why that would matter, ENV vars are a standard mechanism of already compiled OS processes, so reading ENV during compile should affect the compilation process, not, for example, inject secrets into the final binary. But I have little experience of Elixir, so I'm sure I'm missing something important here.

[jarednorman]

It is entirely possible that you could inject your secrets into the compiled result through macro use. It would totally possible without realizing you had done it.

Additionally, many apps do not build in the same environment they deploy, and this has caused issues repeatedly for users of this library, who inadvertently inject values into the compiled result that are blank because a macro inserted them at compile time but they are only available at run time in the production environment.

I agree that Phoenix's use of ENV variables is sensible, but this is not a tool that you should use for managing that stuff. I've not used it, but someone recommended Envy in another issue, and that might be a better fit.

[jarednorman]

I've updated the README to avoid implying that using the ENV to manage secrets is bad.