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

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).

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

@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.

Thank you all for the input! @al2o3cr I know that putting System.get_env/2 anywhere outside of a def block (e.g. in a module attribute) generally means it is evaluated at compile time (and the compiler now warns about this and it helpfully suggests using Application.compile_env/2 instead).

But I learned something from @v0idpwn : during regular development the config.exs file is read at runtime! What I was remembering was that during RELEASES, snapshots of the system ENVs are taken. So if you compile the app via FOO=bar mix release, then the value of that ENV var is compiled into the app and even if you start the app with a different ENV value, e.g. FOO=ignored _build/dev/rel/myapp/bin/myapp start, it will use the value that was read as the time of compilation.

This is not true, no system env vars are implicitly baked into the release. If you read values from the env at compile time such as with @foo System.get_env(…), then those values will be compiled into the code, but only because you did that.

I also recommend using config/runtime.exs for everything that is not necessary to be set at compile time. It’s just less headache and surprises that way.

Tangentially, you may want to try SayCheezEx 📸 — say_cheez_ex v0.3.6 to get a friendlier approach to building environment/version strings.

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.

These are application environment values, not operating system environment variables.

Ah, it seemed to me (and it still seems) that he was referring to when you read system env on application configuration, you’re effectively snapshotting it. Otherwise its pretty obvious that its read at runtime.

The IO.puts here is a placeholder for System.get_env