Just to get some closure, this is all solved with Mix Releases, correct?
Yes. import Application.Config in the proposal became import Config. Elixir v1.11 introduces config/runtime.exs, which applies both to releases and Mix, unifying both.
3 Likes
Is there a standard way to have one release, multiple runtime.exs for running multiple, concurrent instances on the same machine? I guess we can do:
config_provider: [{Config.Reader, {:system, "RUNTIME_ROOT", "/runtime.exs"}}]
In the mix.exs Then mess with $RUNTIME_ROOT before starting of the release?
1 Like
You could generate multiple releases with the following:
releases: [
a: [
runtime_config_path: ...
],
b: [
runtime_config_path: ...
],
…
]
I don’t want to generate multiple releases, because I don’t know how many in advance. It can be useful in situation like multiple users running the same release, each with their own config.
Many server software can read in an alternative config file from command line switch or preset environment variable. I wish elixir release can do the same.
I guess in that case runtime.exs is not what you’re looking for, but actually what you proposed. Releases are meant to be self-contained, but your use case makes that impossible by definition. So I guess a custom config provider is the cleanest way to go.
For user specified configuration, eg through JSON, TOML or even system environment you could use config providers.
This approach would work, yes!
This thread-necromancing really messed with my head 
I read like 10-15 posts and was like “uh huh this sounds great, but maybe a bit much now that we have runtime.exs?” before I saw the timestamps.
1 Like
