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
tfwright
I infer from your preable that you are specifically looking for technical answers, but since you mention this purpose I am curious why in such a situation you wouldn’t just use a single default “example” file and modify/copy it to the “real location” as needed, which I think is a pretty standard way to handle this kind of thing?
I suspect any real answer to your question would benefit from similar details, because answers to a question like “can I” generally come with a lot of “depends”…
arcanemachine
I thought that didn’t work for runtime config?
I need to look into this again…
EDIT: Got this error: ** (RuntimeError) import_config/1 is not enabled for this configuration file.
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
We build reliable cloud platforms for business-critical systems.
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Develop your skills with books, videos, and courses.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
Courses that'll move you from confusion to "Aha, now I get it!"