(I have found some threads in the forum that in one way or another touch this topic, but none of them solves this question in a clear way.)
As you know, build time configuration is located in config/config.exs, Mix uses that file to generate the application resource file, which contains the hard-coded application environment, among other things.
On the other hand, we have now config/releases.exs, which is evaluated at runtime, but only for releases.
Now, in my project everything is set via system environment variables regardless of the type of server. So, for example I have
Is it correct that despite the intended uniformity, I have to repeat that line in config/config.exs and in config/releases.exs?
Is there a way to avoid that duplication? I was thinking about creating config/common.exs, to be imported in both files, but the docs for mix release say you cannot use import_file (does it mean import_config?).
If it suits your use case you can call import_config("releases.exs") from inside config/config.exs, which would allow you to only specify it in one file.
It doesn’t work for me, because there is production stuff that it is not common to the rest of environments.
I have come out with a solution, it is not very elegant, but seems to work correctly in my proof of concept.
First of all, the new Config module is unrelated to Mix, which is the point. Therefore, I argue that it should be possible to invoke import_config/1. Granted, there is a MUST NOT in the docs, but I don’t see it justified looking at the source code. Perhaps it is being too generic assuming a common Mixish invocation pattern?
Secondly, the priv directory is included in releases and available in a robust way via :code.priv_lib/1.
Therefore, we can have a hybrid approach. In config/config.exs you write:
Someone else will have a more qualified answer than me, but I know configuration was thought long and hard about for the inclusion of releases in Elixir 1.9, and I think there was a good reason why they did it this way - especially since they call it out so clearly in the docs.
Well, since import_config is not allowed in config/releases.exs currently, I don’t think this is very practical.
In earlier projects (using Distillery 1) I opted for using the Conform approach. Here, you have to maintain the release configuration in an entirely different format, and then define how that is transformed into Elixir terms - which is a lot more overhead than maintaining config/releases.exs, but also gives a cleaner/stricter interface to configuration. It should be similar to using e.g. a YAML configuration provider with 1.9 releases.
I only have a small app that uses the new Elixir 1.9 releases, and in this app, there’s very little overlap between the Mix config and the config/releases.exs. I currently hardcode configuration in the Mix config files, and allow a few variables to be specified as environment variables that are read at runtime in config/releases.exs. So far it has worked fine for me, but as I said this application is quite small.
Lately, I prefer using the application environment as little as possible - only using it for the configuration that I cannot specify/change after my application has booted. This preference comes from excellent blog posts like this one by @sasajuric. I don’t use that approach exactly, but the ideas definitely informed the way I tend to do configuration today. Also, libraries like Specify or Vapor are pretty interesting.
I’m the author of Vapor so obviously I’m biased. But my preference is to completely avoid all of the config/**.exs files for runtime configuration. Its way more trouble then its worth. Vapor is a formalization of the patterns that I’ve been using to manage configuration values in the services I maintain. The library itself has gone through a few different iterations but overall its been useful.
Exactly. There is a gap between config/config.exs and config/releases.exs, because one is compile-time and the other is runtime. That’s why it has been historically awkward to do runtime configuration for Mix. config/releases.exs solves it, but only for releases. We are aware of the issue and we have a proposal in draft, to be included on v1.11, that makes it clear what is compile-time and what is runtime. This should be the last stop in our journey to improve Elixir configs that started back in v1.9.
I’m working on a blog post about how we use vapor which will have more detail. But all we do is specify our configuration as a function in our Application module. The function is typically named config!. The function calls Vapor.load! with the configuration providers. The first function we call in app start is config!. Once we’ve loaded everything, we can pass values down to our children processes.
The main benefit to this approach is that it skips configuration files altogether. Loading configuration is identical whether we’re in dev mode or production mode.
Not sure if useful information, but to deal with wanting runtime configuration outside of a release, for stuff like development shells and running tests, rebar3 simply duplicates the support for sys.config[.src] that running a release has.
So I think the equivalent would be if iex -S mix and mix test were able to load application environment from config/releases.exs.
Is the proposal on the elixir-lang-core list or in this forum somewhere? I’ve searched both places and found very long threads but couldn’t find v1.11 draft plans to improve this. Trying to decide whether to adopt one of the nice community runtime config systems or wait for v1.11.
