arcanemachine
Can I use `Code.eval_file/1` to dynamically import runtime config?
Preamble: I am aware of other methods of dynamic runtime configuration (e.g.
Config.Provider), and am currently a happy user of Dotenvy. The title of this thread is not “How to dynamically configure runtime config?”, but is specifically pertains to the usage ofCode.eval_file/1as a strategy to do so.
I am experimenting with different strategies to dynamically import runtime config, similar to how Config.import_config/1 works for compile-time config.
I have come up with a solution that appears to work. I am bringing the topic here for discussion, to see if there are any valid technical reasons why I should not use this strategy.
The strategy
Here is an example config/runtime.exs that uses Code.eval_file/1 to import a local runtime config file, if one exists:
config/runtime.exs
import Config
config :my_project, :hello, :world
# Maybe import local runtime config file(s)
for local_runtime_config_file_name <-
["runtime.local.exs", "runtime.#{config_env()}.local.exs"] do
local_runtime_config_file_path = Path.join(__DIR__, local_runtime_config_file_name)
if File.exists?(local_runtime_config_file_path) do
IO.puts("Importing local runtime config from `#{local_runtime_config_file_path}`...")
Code.eval_file(local_runtime_config_file_path)
end
end
This allows one or more (presumably gitignored) local runtime config files to be added, without having to modify the main runtime config file:
config/runtime.local.exs
import Config
config :my_project, :hello, :another_world
The above example shows how a local runtime config file could be loaded for 1) all configuration environments, and/or 2) a specific configuration environment (e.g. :dev, :test, etc.), and supports cascading (i.e. the global runtime.local.exs would be overridden by e.g. runtime.dev.local.exs). If any of the local files do not exist, then that is fine also, and no custom config would be loaded.
I have this running, and it appears to work. But I haven’t seen this strategy documented anywhere, so I’m a little wary of using it.
Does this appear to be a viable strategy, or is there some hidden footgun here that I am not aware of?
Most Liked
LostKobrakai
Instead of answering the question I’ll answer why this isn’t a feature in the first place:
Runtime config needs to be copied into releases, so the config can be executed when the application boots. That copying means mix needs to know which files to copy in the first place statically – it cannot run the config file to figure it out, because conditions might change. Therefore to keep things easy elixir limits runtime config to a single file by default, which has to exist with a known name at a known location. All this happens under the premise that a release once assembled can be copied as is and is startable.
Now you can manually make sure additional files are also copied into the release and then you could read them. It would retain all the properties elixir/mix tries to uphold from it’s pov knowling less details about your project. I’ll leave the judgement if that’s a good idea to yourself though.
LostKobrakai
Personally I skip file in the equation. All the things that need to be set from the outside at runtime need to come in as system env variables. runtime.exs reads those. But elixir/mix/releases are not at all involved at setting those variables. For that I tend to use direnv locally / in development and whatever tool my deployment target provides to set environment variables. Those may or may not be able to source from files committed to the repo itself - e.g. .envrc for direnv can be commited, but a systemd unit might live elsewhere – so first and foremost I want to provide documentation (and good errors) around the set of expected env variables, rather than trying to prescribe how downstream people have to provide values. The runtime.exs essentially becomes a mapping from system env input to elixir config values for the minimal set of what should be configurable at runtime.
mudasobwa
I might be missing something, but what would be wrong with plain old good Config.import_config/2?
for config <- ["runtime.local.exs", "runtime.#{config_env()}.local.exs"] |> Path.expand(__DIR__) |> Path.wildcard() do
if File.exists?(config), do: import_config(config)
end
Last Post!
adamu
It sounds like you have a local uncommited .exs file that is duplicating the role that runtime.exs in plays in a release. So in the uncommited .exs you are setting up config using elixir, and runtime.exs you are setting the same config via environment variables.
It might simplify things to remove the ability to have any uncommited local config, and have any customisations set via environment variables via runtime.exs locally, too. That way, if a dev forgets to commit the config, it will fail to compile on CI / for everyone else.
edit: whoops, posted before seeing the above post. I think we’re saying the same thing.
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex









