I personally think they shouldn’t. In most cases, a library should take it’s parameters as function args (or return value of callback functions), and not enforce how this data is provided.
I would argue that using config scripts is splattering the data all over the place. For example, consider endpoint parameters which are by default sitting in four config scripts (config.exs, dev.exs, test.exs, prod.exs), but the ultimate source of truth is still endpoint module, where in
init/2 that config data is further enhanced. Wouldn’t it be more consolidated if you listed all the endpoint parameters in
It’s been a really long time since I’ve worked with Rails, but my memories of its configuration and initializers are not good memories I prefer an explicit mechanism which fits well with the standard way of writing Elixir code. We already have that for our applications, and I think we could have the same for booting of the entire system.
Just call something like
In a simple scenario, there could be a wrapper module for fetching stuff from the configuration storage. Let’s call it EtcdConfig. Then other modules, such as endpoint and repo call the functions from such module.
In a more complicated scenario, you might want to cache these parameters, maybe periodically refresh them. In such cases, I’d use a dedicated ETS table (but not app env), and the implementation would become more complex, involving a couple of processes. But still, from the client’s perspective things would be simple, as client modules would just call well defined functions from the module responsible for fetching the data.
That depends on how the library accepts values.
If it accepts them as function parameters, or callback function return values, then it’s as simple as
If it requires app env value but not during its boot, then it’s more complicated, but it can be handled during the client app’s
If the library requires app env value during its boot, then currently we have no good solution, and need to resort to various kind of trickery.
You lost me here. What sort of situation warrants a centralized place, what would such place be, and what belongs to the config to begin with? This words gets thrown around a lot, but I haven’t seen anyone explaining when some piece of data is consider a “config”, instead of just plain function argument.