I’ve said it elsewhere, but I want to repeat again, that I believe that libs should in most cases not be prescriptive about configuration. This tweet mostly mirrors my way of thinking:

https://twitter.com/timperrett/status/841163004968239104

I wouldn’t be as harsh and say that there are no such scenarios, but I do feel that in most typical cases libs should just take their options at runtime, either through function parameters, or through module callbacks. I believe that this will simplify many deployment/config challenges

Let’s see how runtime configuration would address your original concerns:

Confusion as config being compile time, including reading the environment

If a library takes options at runtime, then you need to pass the value at runtime, so there’s no confusion.

{system, “MYENV”} being somewhat present but considered bad practice by @josevalim

If a library takes options at runtime, then we don’t need {:system, ...} or any similar improvisation.

Difficulties around secret handling

If a library takes options at runtime, it’s up to developer to read the secret at runtime from an arbitrary safe place.

No standard way of defining config requirements/schema for libraries

If a library takes options at runtime, then requirements can be listed as mandatory parameters, while schema can be specified with typespecs.

Therefore I believe that the best solution is to educate lib authors to seriously consider whether their libraries really need to be configured through config.exs.

The changes happen on two different levels.

Internally: it means that Ecto will internally expect configurations to be set at runtime rather than compile time.

Externally: it means that Ecto will provide a proper API to do runtime configuration. The only way to do runtime configuration in Ecto 2.0 was by using url: {:system, "DATABASE_URL"} which has two big problems: it only works for the :url parameter and it only allows the configuration to be read from the system environment. If you need to read it from elsewhere, you are out of luck.

Ecto 2.1 now provides the init/2 callback inside your repo for runtime configuration:

def init(_, config) do
  {:ok, Keyword.put(config, :url, System.get_env("DATABASE_URL"))}
end

Now you have the flexibility to do whatever you want. Also note Ecto allows the configuration to be given at the moment you call start_link on the Repo.

Can we put that in boldface and blink? In fact, it should trigger a compiler warning or linter error.