A universal way to detect environment in Phoenix?

Phoenix Forum Chat / Discussions
,
1

When deploying a release via “mix compile / release”, Mix may not exist on a server, right? Therefore, if Mix.env() == 'abc' won’t work.

What is it then a way to detect the current environment? A one which would work everywhere, whether it be in dev or production or any other custom environment that I may create. And a one which won’t require copy-paste, and which will update itself automatically. Namely, merely using an environmental variable won’t work because what if I launched a project in prod. enviroment but locally? And then in dev. env again locally too. Or in dev. environment on a server? An env. variable would hold the wrong value half of the time - unreliable solution.

Also note that on a server I may use systemd or rc.d service, therefore simply using .env file although would work locally in dev env, wouldn’t on a server because it’d require copy-pasting the env. data into systemd or rc.d services and I want to avoid copy-paste.

2

I’m not 100% sure what you’re after, but neither Elixir / Phoenix nor any other programming platform can automagically know if you intend to run the program in “production” or not when you start it.

You have to figure out how to make it work for you.

In our case, we deploy to AWS, with different accounts for test & prod. The app picks up configuration from Secrets Manager, in the form of secrets for eg. database access (hostname + user + password). The secret is always called the same name, but has different contents in the test vs prod accounts.

If we run locally in Mix dev mode, it will just pick up environment variables. If running locally in Mix prod, it’ll pick up the relevant secrets depending on which account the AWS_PROFILE env var points to.

2 Likes
3

The thing is that hardcoding Mix.env() checks in your application is confusing and error prone. Instead, try using the application configuration and setting the proper values in your dev/test/prod. This way an operator of the system can see all behaviour that is different between dev/test/prod without having to grep for Mix.env() checks in the codebase.

2 Likes
4

Do you suggest that I hard-code “current_env: :dev” in config/dev.exs and “current_env: :prod” in config/prod.exs? This doesn’t make sense because how does the appropriate enviroment config file get loaded in the first place? Where does Phoenix itself get information about the current environment from and therefore which env. config file to load?

And it’s not about setting values in dev/prod/test. It’s about checking the current environment itself. It’s because in some places in my project I need to check whether or not, for instance, the current environment is dev, in others – if it’s prod, in others – if it’s staging, in others – if it’s my_custom_env.

5

Application.get_env?

Can you provide a stricter example of need? It sounds like a code smell.

I am assuming that say, in Prod you want to hit a real remote service, but in dev you want to hit something else or not hit anything at all.

IMO you should keep your code the same no matter the env and swap in/out a stub service to act as the API where required.

E.g:

Dev -> CreateTicketMock() # does nothing
Staging -> CreateTicketAsFile() # write to local file
Prod -> CreateTicketInHugeInfrastructuerWithExternalService() # actually do something

And your config/dev|prod|staging sets an appropriate value for the application to load the right service, so your code is just TicketCreator.create_ticket(...) no matter the environment.

1 Like
6 
if current_env == a do
  # something
end

if current_env == b do
  # something 2
end
7

Yes, but why.

2 Likes
8

No, instead have a config for each specific behavior. For example, imagine there is an external service which provides both dev and prod URLs, make that a configuration instead of checking for the environment inside the code.

1 Like
10

And it’s not about setting values in dev/prod/test. It’s about checking the current environment itself. It’s because in some places in my project I need to check whether or not, for instance, the current environment is dev, in others – if it’s prod, in others – if it’s staging, in others – if it’s my_custom_env.

The behaviour of some parts of my project would differ depending on the current env. That is, I may do something in case the env. is “dev”, and don’t do it if it’s “my_custom_env”, and do something different if it’s “prod”.

11

Why do you have to have the if in code and not just inject the correct delegate when the service boots though?

Anyway, I believe Jose is saying set whatever you want to check in the appropriate config file, you can then get that with Application.get_env or you can use System.get_env if you want to get an regular system environment variables. You could probably do config :my_app, :execution_env, Mix.env() in config/config.exs I guess then Application.get_env(:my_app, :execution_env).

I think Jose is also implying that instead of checking against the env en todo, it’s better design to check against specific configurations, which is more readable and maintainable:

if Application.get_env(:my_app, :do_use_service) ...
if Applcation.get_env(:my_app,  :logging_is_enabled) ...

vs

if Application.get_env(:my_app, :mode) ==  :dev then do_use_service()

See h Application.get_env and h System.get_env in iex.

4 Likes
12

I guess you could define a module attribute?

@current_env Mix.env()

defmodule MyModule do
  def current_env, do: @current_env
end

…and then use it wherever you need. If I’m not mistaken, it should be evaluated at compile time, so if compiled for Mix env = dev, will always be “dev”, etc.

13

Though, if actual behavior differs between environments, do try to keep the differing code minimal, as it will be difficult to test. Best perhaps to wrap the case for each environment in its own function, even, that you could at least specifically call from tests?

14

How is the 1st better than the 2nd?

1 Like
15

Because this may infer a lot implications that are hard to understand for a second person (or your future self).

# checked in
#   - my_mod.logger to decide on which logging endpoint to use
#   - my_mod.xyx.fn() to infer abc or ars.
config :my_app, :mode, :dev

And then one day you set :mode = :prod but the check never accounted for it or forgets to check and you have a very hard to find bug in some obscure location.

Or you want to have two staging envs and now you’re updating all your if/case to check env == :staging or env == :staging_site_b.

VS

config :my_app, :remote_logging_url, "https://dev.local"
config :my_app, :xyz_use, :abc

Which is both explicit in what you are configuring and allows for finer configuration and should actually remove the need for checks in your code.

case :mode do
  :dev ->  Logger.set_receiver("http://dev.local")
  :staging ->  Logger.set_receiver("http://staging_1.internal-1.com")
  :prod -> Logger.set_receiver("http://www.remote.com")
end

becomes

Logger.set_receiver(Application.get_env(:my_app, :remote_logging_url)
8 Likes
16

Why would I set “mode: :prod” in config/dev.exs ?

18

Values can affect behaviour though and that’s what people are trying to suggest here.

Say you have a UI where you show a secret key. In dev you want to show the whole secret, while in prod (and other envs) only the last few characters are supposed to be shown. This is different behaviour.

defmodule MyUI do
  defp format_secret(<<_start::binary-size(12), rest::binary-size(4)>> = secret) do
    case Mix.env() do
      :dev -> secret
      _ -> "…" <> rest
    end
  end
end

Instead of depending on the environment to select behaviour directly you can bundle up the behaviour (e.g. in functions or modules) and let the environment select the behaviour via configuration.

Step 1: Bundle up behaviour

defmodule SecretFormatter do
  @callback format(binary) :: binary
end

defmodule SecretFormatter.SecretFull do
  @behaviour SecretFormatter

  @impl true
  def format(secret), do: secret
end

defmodule SecretFormatter.SecretTail do
  @behaviour SecretFormatter

  @impl true
  def format(<<_start::binary-size(12), rest::binary-size(4)>>), do: "…" <> rest
end

defmodule MyUI do
  defp format_secret(secret) do
    case Mix.env() do
      :dev -> SecretFormatter.SecretFull.format(secret)
      _ -> SecretFormatter.SecretTail.format(secret)
    end
  end
end

Step 2: Use config to select the behaviour

# config.exs
config :my_app, MyUI, secret_formatter: SecretFormatter.SecretTail

# dev.exs
config :my_app, MyUI, secret_formatter: SecretFormatter.SecretFull

defmodule MyUI do
  defp format_secret(<<_start::binary-size(12), rest::binary-size(4)>> = secret) do
    formatter = Application.fetch_env!(:my_app, __MODULE__) |> Keyword.fetch!(:secret_formatter)
    formatter.format(secret)
end

This is quite a bit longer as you can see, but this is also the most elaborate setup with gives you a lot of compiler help, the ability to mock things using Mox in tests and such. You could also just name the two different ways to format things and configure the name for each.

# config.exs
config :my_app, MyUI, secret_format: :tail

# dev.exs
config :my_app, MyUI, secret_format: :full

defmodule MyUI do
  defp format_secret(secret) do
    case Application.fetch_env!(:my_app, __MODULE__) |> Keyword.fetch!(:secret_format) do
      :full -> secret
      :tail -> "…" <> rest
    end
  end
end

The important bit is that you put the different code paths (currently per env) into something independently callable and make the decision which of those to call a configuration concern instead of compile time or runtime decisions in the codebase itself.

The second example might also show that Mix.env is also just a value you use to make decisions. It’s just way less flexible and less visible than using configuration. Configuration allows you to map env => behaviour in one common place instead of scattered all over the codebase.

7 Likes
19