This is a great point that it would be pretty hard to pass anything but strings. And validation too. What still bothers me is that it might be pretty hard to keep track of settings if they are spread over config.exs and init simultaneously. I'll probably go with this Config module idea, thanks. At least until there's a common solution.
On Monday, August 6, 2018 at 6:25:18 PM UTC-7, Paul Schoenfelder wrote: > > > So the idea is to individually resolve these settings in init callback, > am I getting it right? > https://github.com/elixir-ecto/ecto/blob/master/lib/ecto/repo.ex#L69-L75 > > Well, if I do that, I'll have to use the ENV variable in dev environment > as well, which I wouldn't want to do for obvious reasons: these old configs > are just code, when env variables are volatile. > > I think you are missing the fact that the resolved environment variable > can be set conditionally, i.e. only when there is _no_ value found in the > application environment. You can do whatever you want in that callback. But > yes, the idea is that if there is no value found at that point, you can > attempt to resolve configuration from the system environment or elsewhere - > it becomes part of your application code and lives alongside the thing > being configured. > > > And what is the rationale, why {:system, var} is so bad if what happens > in init callback is essentially the same? Am I missing something here? > > It isn't the same - one is implicit, the other explicit, amongst other > things - in addition, the behavior of `{:system, var}` is not well defined, > it depends on the implementation; there is no way to handle converting > values to appropriate internal types (i.e. an atom or an integer) or > provide defaults. There is no way of knowing if that tuple is used for > other purposes in some application or library somewhere or not - the > convention was created by Elixir libraries early on, but there are far more > Erlang libraries and Elixir libraries which do not use it than those which > do, automatically transforming that tuple to the value of the system > environment variable is "magical", and is something we in general try to > avoid, particularly in cases where it may cause issues with existing > applications. > > By putting configuration handling code in the `init` callback, you can > handle falling back to multiple sources, perform type conversions, > validation, and more, is explicit, and becomes maintained with your other > application code. If you are looking for something that would do that sort > of conversion for you, you can simply write a thin Config module which > checks for that tuple, and resolves the environment variable, and just > invoke that module from the init callback instead. > > Paul > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/ed34aba1-e22f-4591-a019-6b11dbc19cea%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
