@thousandsofthem Validation/transformation of the raw config prior to use is best left for init functions in the relevant parts of your application, you have to do validation at these points anyway, I see no reason why one would prefer config.exs for that - I only ever use config.exs to define default values, everything else is handled internally in the application. In my apps, I’ve usually extracted common config logic into a Config module which I then use in init callbacks of my application. You can also use start phases (or just the start callback) to pull config from external systems (for example Vault or something), and do what you need to with it prior to starting your application’s supervisor tree. There are other options as well, such as my conform library, which allows you to do complex validation/transforms of config pulled from either an ini-style config file or from environment variables, and this transformed config is then used by the release.
I often wish that José had gone a different route with config.exs - we wouldn’t be having this conversation, because everyone would just do configuration the way I described above, which is how it’s been done in Erlang for years, and this would be a non-issue, but instead people get used to doing everything in config.exs, and then find that it’s a pain to transition away from it when they want to start using releases - well, yeah, it sucks you have to do that, but it’s not that configuring releases is somehow terrible, because it’s really not, it’s that you have to refactor your code to handle configuration differently. And yes, that’s a valid complaint, but placing the blame on releases is not.
