A universal way to detect environment in Phoenix?

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.

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.

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.

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.

if current_env == a do
  # something
end

if current_env == b do
  # something 2
end

Yes, but why.

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.

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

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.

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.