Does this mean that on_boot would replace use Application.Config?
sasajuric
Author of Elixir In Action
josevalim
Creator of Elixir
@sasajuric theoretically there would be no need for Application.Config, as outlined in this proposal, but I still think we need to have Application.Config in case anyone wants to customize a release after it is assembled (and we can’t depend on Mix by then as well). In other words, I would still introduce Application.Config but it is for another purpose rather than file discovery (it could even be a separate proposal).
0
sasajuric
Author of Elixir In Action
@josevalim Right, I’m just trying to figure out what’s the choice here. So if I get it right, you’re now asking us what do we think about use Application.Config vs on_boot, where the latter would be used to explicitly denote the parts which are evaluated at runtime?
I.e. with on_boot, it would look like this:
# we're using mix config, as before
use Mix.Config
on_boot do
# evaluated at runtime
config :ui, UI.Endpoint, url: [host: System.get_env("HOST")]
end
# evaluated at compile time
config :foo, :bar, System.get_env("BAZ")
Is that the choice?
0
net
josevalim
Creator of Elixir
Almost. Let’s forget about Application.Config completely. The choices are:
- Introduce
on_bootas an explicit block of code to be evaluated on boot (e.g. during a release or during mix app.start)
OR
- Restrict
import_configto be static we can copy configuration files as is to a release and have the same configuration files be executed at both compile time and runtime without a distinction of “when” each is happening
0
sasajuric
Author of Elixir In Action
Ah, that sounds neat, and it seems like it’s a smaller change from the perspective of user devs. In addition, as others have mentioned it, it makes the execution context explicit, which seems like a better choice.
Why did you settle on the current proposal then?
1
josevalim
Creator of Elixir
The current proposal was seen a smaller step. We could always add on_boot later and we thought restricting import_config was going to be a good thing nonetheless. But I guess the opposite direction is also true: we can add on_boot now and restrict import_config later.
3
yurko
on_boot/1 sounds good 
One question though, from the initial proposal I had a feeling that it’s a “hack” or a “workaround” that would temporary make stuff clearer without fixing anything, but reading the discussion I get a feeling that it’s a first step towards unifying the configuration and the workings of mix and releases, is that so?
There was an article describing the general direction Elixir is moving: Elixir Deployment Tools Update - February 2018 - DockYard
To remove the awkward transition between development and production, we really need our development tooling to be built on releases under the covers. In short, if you run iex -S mix or mix run, these should effectively be the equivalents of bin/myapp console or bin/myapp foreground. If you are always running releases, then there is no transition to be made between development and production.
I very much like the idea, am I right to assume that it’s still the end goal?
2
talentdeficit
Rebar3 Core Team
i think the core problem with elixir’s use of an executable script to populate the application env and the use of Application.get_env/3 as the means to retrieve config is that it makes it acceptable and idiomatic to put configuration in config.exs. this is fine for examples and most standalone apps but it breaks down for users who have to integrate elixir into existing ecosystems where things like vault/etcd/dynamodb/encrypted json blobs/etc are used. at two different jobs i’ve had to fork phoenix, ecto and other applications to break their dependence on an evaluated config.exs to allow for use within the environment that was already established. at my latest job i’m just not using elixir because the burden to introduce it was too high
i don’t think there’s anything wrong with either of these proposals but i think incremental improvements to config are not enough. the risk is that it gets good enough that no further work is done and the real issue (that of libraries not exposing their internals in a way that is flexible enough for more than just archetypal users) is never addressed
5
sasajuric
Author of Elixir In Action
Not sure about other apps, but with ecto/phonenix there was always a workaround without a fork. The way I solved it in older versions was to populate the missing pieces of app env in my app start callback before starting the supervision tree. It wasn’t very pretty, but it worked. These days, we have a proper solution for Phoenix/Ecto in the shape of init/2 callbacks (see here and here).
IMO overreliance on app env is not just Elixir’s problem. I’ve seen it happen with Erlang libs as well. In fact the most annoying episode I had was with riak_ensemble which loads the database storage location during its startup (so before my app startup), which made it very hard to establish a local cluster by starting multiple instances from the same folder. In the end, I resorted to included applications to work around it, but I really disliked it.
I share this sentiment too. I believe that in a mid-to-long term it would be better if we motivated developers, and in particular library authors, to avoid app env unless absolutely necessary. The next version guides already have good recommendations, but I also think that the generators (mix new and mix phx.new) could push people towards configuring at runtime, to promote the culture of preferring runtime configuration via function parameters and/or callback modules.
That said, both proposals look fairly lightweight, and they should help solving at least some common confusion and ugly workarounds (such as replace_os_vars), so I think they are a good short term solution to frequent problems.
4