fireproofsocks

Config.exs and System.get_env/2: are values actually read at runtime?

I thought I had a handle on how Elixir configuration worked, but now I’m thinking I missed something. My memory was that the config.exs file gets read at compile-time. So if my config.exs contained the following:

# config.exs
config :myapp, :foo, System.get_env("FOO")

Then I could compile an option into it via

FOO=bar mix compile

and starting up the app would yield the value that I set at compile time, e.g.

iex -S mix

# Expected:
iex> Application.get_env(:myapp, :foo)
"bar"

But the actual result is nil. Or whatever the System ENV is set to at runtime – and the app does not re-compile.

So my question is: is config.exs actually reading values at runtime? Or is it doing something special with System.get_env/2 so it resolves at runtime? Am I going crazy? I don’t remember it working this way. Thanks for any clarifications!

12 comments

#config

18 2497 12

2023-06-14 13:58:23 UTC

Most Liked

v0idpwn

The environment is set by mix when starting up, both in compile time and when running your application. If you’re using releases, then the config is set at the point where the release is built (except for runtime.exs, which is evaluated at startup in releases as well).

Post #2

al2o3cr

config.exs is still an exs file, so it’s evaluated at runtime.

My guess is that you’re remembering two similar things:

using System.get_env in some places in modules will result in the “stay until the next compile” behavior you describe:
```
  defmodule SomeModule do
    @foo System.get_env("FOO")

    def foo, do: @foo
 end
```
SomeModule.foo will “capture” the value from ENV at compile-time
using System.get_env in config.exs will result in a “stay until the next release” behavior for environment variables, thus the need for runtime.exs

Post #3

lud

@v0idpwn I am surprised actually, I too was believing that this was compile-time only but indeed the values defined here must be available at runtime and are not stored into a file like in a release.

So the runtime execution erases the value set before compilation.

What is confusing is that if you wanted to have this config:

import Config
config :demo, foo: System.get_env("FOO")

And this code:

defmodule Demo do
  @foo Application.get_env(:demo, :foo)

  def foo do
    @foo
  end
end

You cannot call FOO=bar mix compile and then just iex -S mix and get the expected value, because iex -S mix will always trigger a recompilation. The code above will emit a warning as you should use Application.compile_env. Very different behaviour than calling @foo System.get_env("FOO") directly.

Personnally, I just put everything possible in runtime.exs.

Post #4

v0idpwn

no system env vars are implicitly baked into the release

Yes, they are.

Quoting the documentation, here: mix release — Mix v1.12.3

The :secret_key key under :my_app will be computed on the
host machine, whenever the release is built. Therefore if the machine
assembling the release not have access to all environment variables used
to run your code, loading the configuration will fail as the environment
variable is missing. Luckily, Mix also provides runtime configuration,
which should be preferred and we will see next.

Small demonstration:

# config/config.exs
import Config 

config :config_demonstration, :my_config, , IO.puts """
:::::::::::::::::::::::
:::::::::::::::::::::::
:::: CFG EVALUATED ::::
:::::::::::::::::::::::
:::::::::::::::::::::::
"""

Now, if I run:

v0idpwn ~/oss/config_demonstration [master] $ mix compile
:::::::::::::::::::::::
:::::::::::::::::::::::
:::: CFG EVALUATED ::::
:::::::::::::::::::::::
:::::::::::::::::::::::

Compiling 1 file (.ex)
Generated config_demonstration app
v0idpwn ~/oss/config_demonstration [master] $ iex -S mix
Erlang/OTP 25 [erts-13.1.4] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit]

:::::::::::::::::::::::
:::::::::::::::::::::::
:::: CFG EVALUATED ::::
:::::::::::::::::::::::
:::::::::::::::::::::::

Interactive Elixir (1.14.3) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)>

You can see it was evaluated both at compile time and when starting the application with mix.

Now, I will generate my release:

v0idpwn ~/oss/config_demonstration [master] $ mix release
:::::::::::::::::::::::
:::::::::::::::::::::::
:::: CFG EVALUATED ::::
:::::::::::::::::::::::
:::::::::::::::::::::::

* assembling config_demonstration-0.1.0 on MIX_ENV=dev
* skipping runtime configuration (config/runtime.exs not found)
:::::::::::::::::::::::
:::::::::::::::::::::::
:::: CFG EVALUATED ::::
:::::::::::::::::::::::
:::::::::::::::::::::::


Release created at _build/dev/rel/config_demonstration

You can see it was evaluated two times.

And run it:

v0idpwn ~/oss/config_demonstration [master] $ ./_build/dev/rel/config_demonstration/bin/config_demonstration start_iex
Erlang/OTP 25 [erts-13.1.4] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit]

Interactive Elixir (1.14.3) - press Ctrl+C to exit (type h() ENTER for help)
iex(config_demonstration@Host)1> Application.get_env(:config_demonstration, :my_config)
:ok

You can see it was not evaluated, yet the result value is there.

Post #8

fireproofsocks

I didn’t mean to cause any confusion. “Snapshot” seems like a good term for how values are read during release builds. Thanks for the link to say_cheez_ex.

I just put everything possible in runtime.exs .

Me too. I wrote the dotenvy package to help make it easier to work with configuration sets at runtime.

The takeaways for me are to evaluate whether or not something NEEDS to be known at compile time. Often, a value can be supplied at runtime just fine. Supplying values at runtime can make testing easier, but there may be performance tradeoffs, so YYMV.

I wrote an article about this Dotenvy and my first dig into config:
https://fireproofsocks.medium.com/configuration-in-elixir-with-dotenvy-8b20f227fc0e

Post #13