After reading through this thread, I’m left wondering what specific problem this proposal is trying to solve, even after it’s been summarized and re-stated several times.
-
Introducing
Application.Configthat would work similarly toMix.Config, but be present within a release whereMixisn’t available.I haven’t seen much discussion about this point, which perhaps indicates that people would be fine with it, assuming that it all behaves equivalently to the way it does today.
I personally think it would be an improvement if we didn’t have config files being included dynamically, because it tends to make it difficult to figure out what the final value will be, based on several files including each other. It seems that this is more likely to be the case for Nerves-based projects than for others because we often like to work on pieces of the system on our laptops, only using Nerves to deploy the firmware to a real device at the end. That can lead to configuration file trees that pull in different files depending on whether you’re running the whole system on the device (using a release) or just running the Phoenix-based UI on your laptop (using Mix). Under the original proposal, I think it would just be a matter of putting something like this in
mix.exsforeye_fw:# Note: @target is already set normally in a Nerves-based mix.exs file config_paths: [ "../../eye_ui/config/base.exs", "../../eye_ui/config/prod.exs", "config/config.exs", "config/#{@target}" ]This seems fine to me. It keeps things pretty explicit as far as the order in which configurations will get applied, and allows me to not have to copy/paste the contents of the config files depending on which thing I’m trying to run.
-
Assuming that the configuration doesn’t rely on
Mix, should we apply the same config file both at compile time and runtime. I don’t recall it being specifically stated, but my understanding is that this would be a new step as a release is starting up that would process and execute the configuration somehow before starting any of theApplications in the release, so that they can have their configurations readable usingApplication.get_env/2exactly as they do today, but based on the run-time environment of the release.There are a lot of opinions in the thread, and it’s unclear to me whether we’re specifically trying to:
-
Reduce confusion that people often have initially about whether the
config.exsis applied at compile time, runtime, or both. -
Patch over existing libraries that are doing the “wrong thing,” or allowing/encouraging their users to do the “wrong thing.”
-
Solve the question of how library authors should allow/encourage their users to specify compile-time vs run-time options and settings going forward.
For example, would this problem be solved without making any changes at all to Mix and releases if libraries consistently supported a way for the user to specify that they want to read from an environment variable at runtime (like
{:system, "DB_URL"}or just"${DB_URL}") instead of Mix literally callingSystem.get_env("DB_URL")in the configuration script at compile time? Could we solve the problem by doing whatREPLACE_OS_VARSdoes, only from inside the release instead of the way it works now by rewriting the release config? -
Solve the question of how library users should specify settings going forward. In particular, for the common case that they want to read environment variables at run-time and not at compile-time.
-
Handle all the unusual cases people currently have in their
config.exsjust because it’s there and it’s an executable Elixir script.
-
-
Assuming that we are going to run the same configuration at compile-time and run-time, should we have a way for the user to only run certain parts of it (via
on_boot) or not run certain parts of it (viaon_compile).If the current guidance for library authors is that they should avoid using application configuration, maybe we end up needing
config.exsless and less because the docs for the libraries will tell them to pass options into theirinitcallback instead of putting something inconfig.exs. If that’s the future, then maybe there’s nothing to actually change about the way it works other than libraries, documentation, and community culture.For example, if the
config.exswere only used to declare which environment variable to use and what its default value should be if not set, then it doesn’t matter whether you’re running in a release or not because it’s only declaring the name of the environment variable at both compile time and run time, not its contents. It would be up to the library to substitute the value at the time it needs to.What I’m getting at here is that maybe we don’t need a generic
on_bootmacro that can execute arbitrary Elixir code, if the real problem we’re trying to solve is how to declare that we want to read from an environment variable and what the default value should be if it’s not set.
) It makes the contract explicit and would require the library writer to specify the type of configuration, compile time or runtime, based on the implementation.
As a user, I would love to not have to care about this. Imagine how confusing it will be if every time I want to configure an application I need to figure which one of those buckets I need to put my configuration in. The only case where a 
