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.
