Trying to build something that supports validated modification of configuration values at runtime, well after boot-time, makes it clear how there are really 3 different contexts: configuration that is required at compile-time, configuration that is read at runtime, and the special case of runtime configuration that should be required for the application to boot successfully.
To support strongly-typed, validatable configuration values, that can be modified post-boot at runtime, I’ve been wanting to separate the boot-time special-case into its own discrete concept, so that I can perform validations of said configuration within the Runtime application’s boot cycle, to fail fast instead of waiting for said values to be read at a later point in runtime and only then be discovered to be invalid.
For example, I’ve had Elixir, Ruby, and Python applications where something like the equivalent of a ERROR_REPORTING_SYSTEM_CALLBACK_URL was mis-configured as an invalid url in certain environments. The applications booted happily and ran for days until trying to report an error, and only ate dirt when trying to use the mis-configured value at runtime (with the exception of the Elixir application, which recovered thanks to supervisors, but delayed discovery of the issue for weeks). Boot-time validation of that runtime configuration value would have saved me many times. When the error reporting url is mis-configured, you’re deeply screwed.
This is the sort of very specific issue I’m trying to provide tooling address, but I agree the juice is not always worth the squeeze for simpler applications. I do like the idea of providing a solution to the config/when-the-hell-am-i-loaded-or-modifiable.exs confusion along the way for even simple applications and newcomers by allowing consolidating into config/config.exs alone along the way, though.
