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

Questions / Help
1

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!

5 Likes
2

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

3 Likes
3

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

2 Likes
4

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

2 Likes
5

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.

6

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.

1 Like
7

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

1 Like
8

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.

2 Likes
9

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

10

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.

11

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

12

I know that, the comment is still talking about storing application environment values, whereas I took the original comment to talk about OS environment variables being stored implicitly somehow.

13

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

2 Likes