View Source Configuration Providers
Configuration providers are most often invoked in the context of releases. Although they can solve certain problems that arise in production deployments, they tend to be an awkward fit for regular day-to-day development. Dotenvy
seeks to normalize how configuration is loaded across environments, so having different strategies and functionality depending on how you run your app is antithetical. We do not want some code that runs only in certain environments and not in others: it can make for untested or untestable code!
Secondly, configuration providers sometimes shift the task of "shaping" the configuration out of Elixir and into some static representation (e.g. JSON or TOML). The allure of a straight-forward static file is deceiving because there is no easy way to delineate Elixir-specific subtleties. such as distinguishing between keyword lists and maps. For example, how do you distinguish between a keyword list and a map in TOML? Or how to differentiate a tuple and a list in JSON? And how can you indicate a map with string keys or atom keys?
The takeaway is that When configuration providers "solve" one problem, they often create another and mental friction accumulates. It makes sense to handle problems about Elixir-specific data types inside Elixir instead of trying to cram a solution into some unsuspecting static file format.
For these reasons, Dotenvy
does not rely on configuration providers; .env
files are an easier lingua franca. As of Dotenvy
version 1.0.0 and its support of shell commands, it's easier than ever to populate environment variables by using standard CLI tools to read values from password managers or other services. See the page on 1Password for and example.