Gigalixir ENV variables not accessable

Where you get that string? There is nothing in Elixir that will “magically” replace all occurrences of ${VAR} with environment variable VAR.

EDIT: Originally gave a short answer but I see it was easily misunderstood, so giving a longer answer instead.

If you’re deploying with mix you don’t have access to those magic ${VAR} string replacements. Instead, you’ll want to grab stuff from env by using System.get_env. Since config is evaluated at runtime it will read the system env when you run your app, so you have the same behavior between calling System.get_env in some function and in your config.

If you’re doing Distillery releases things are a bit different. The config is evaluated at compile time and so if you put a System.get_env in your config it will run when you build, not when you start the app. Distillery solves this with config providers or this special built in syntax. If you set REPLACE_OS_VARS in the environment you run your release, any ${VAR}s in your config will be replace at run time. You can still run System.get_env in any code that is evaluated at run time, it will still work as you expect.

If you’re deploying with mix, you can get the env variables with System.get_env but if you’re deploying with Distillery you have to set REPLACE_OS_VARS and then it will automatically expand any ${VAR} s you set in your config. This is a feature of Distillery. It won’t go through all your code and replace any occurrence of ${VAR} though.

This is only half of the truth.

It is perfectly fine to use System.get_env in your code, whether you use distillery or mix based deployments.

You have to be careful though when you use environment variables in the config/*.exs files, they will only be evaluated at “mix-time”.

Similar caution has to be taken when reading environment variables in module attributes, but REPLACE_OS_VARS wouldn’t help there either, as distillery only hooks into the application environment at the applications boot IIRC.

I think I need to try the System.get_env() calls.

In my various config files, I have calls like

config :my_app, :important_url, "${IMPORTANT_URL}"

I think I’m doing Distillery releases. The ${DATABASE_URL} is getting set and read by my repo, and when I connect to the remote mix console, the configs all show the proper values, but it’s only when I’m actually running something using the other configs that this fails.

I’m not sure what I’m missing, and I’m more confused because the behavior seems inconsistent (why does the DATABASE_URL variable seem to work by my custom IMPORTANT_URL does not? I’ve re-deployed the app several times after setting those variables, doesn’t that mean that the app re-compiled? And why does the remote iex session have access to the variables?

Maybe if you show us some more code. Could you show the code where you read the config? Note that if you would eg get the config value in a module attribute that would happen at compile time and not reflect the run time value.

@important_url Application.get_env(:my_app, :important_url) would not correctly get the run time value of the environment, it would capture what the config value was at compile time (which is "${IMPORTANT_URL}".

Jola, I think you hit the nail on the head! That seems to be exactly what’s going on. Here is some more code (forgive me for not sharing more earlier):

In my config I’m really specifying an API base url and API keys which change between testing/dev/production environments:

In config:

config :my_app, :some_api, %{base_url: "${IMPORTANT_URL}", api_key: "${API_KEY}"}

In my module I am referencing it via a module attribute:

@api_config Application.get_env(:my_app, :some_api)

So can you help me understand how this is being compiled and how I should refactor it? Is that correct that module attributes get resolved at compile time and so that forces the Application.get_env() to get evaluated? Whereas if I were to use the Application.get_env() inside a regular function, it wouldn’t execute until run-time?

That’s correct. Credit to @NobbZ who pointed it out before me.

@NobbZ thank you too for your guidance! I don’t think I would have figured that out for a very long time.