Use different `extra_applications` values for releases

Questions / Help
, ,
1

I have the following list of apps in my extra_applications field in mix.exs:

  def application do
    [
      mod: {Core.Application, []},
      extra_applications: [:logger, :runtime_tools, :google_maps, :os_mon, :wx, :observer]
    ]
  end

This works great for local development, but, if I want to send it to my prod/dev servers, I need to always remove :wx and :observer because otherwise, the release will be generated with the beam linked to the wx libraries which the servers don’t have installed and it will crash the beam in some specific cases when trying to load the link.

So, considering that, is there some way to configure extra_applications so when I create a release the list will not have :wx and :observer in it?

2

When generating a Phoenix application you have code like:

defmodule Example.MixProject do
  use Mix.Project

  def project do
    [
      app: :example,
      version: "0.1.0",
      elixir: "~> 1.14",
      elixirc_paths: elixirc_paths(Mix.env()),
      start_permanent: Mix.env() == :prod,
      aliases: aliases(),
      deps: deps()
    ]
  end

  # …

  # Specifies which paths to compile per environment.
  defp elixirc_paths(:test), do: ["lib", "test/support"]
  defp elixirc_paths(_), do: ["lib"]

  # …
end

You can use exactly same way in the application function, for example:

  def application do
    [
      mod: {Core.Application, []},
      extra_applications: extra_applications(Mix.env())
    ]
  end

  defp extra_applications(:prod), do: [:logger, :runtime_tools, :google_maps, :os_mon]
  defp extra_applications(_env), do: [:logger, :runtime_tools, :google_maps, :os_mon, :wx, :observer]

Note: It’s more rare, but I guess you may want to run prod with those applications sometimes. The alternative way would be to use an environment variable when compiling or generating release.

  def application do
    [
      mod: {Core.Application, []},
      extra_applications: extra_applications(Mix.env())
    ]
  end

  defp extra_applications(:prod) do
    env = System.get_env("MY_PROJECT_USE_WX", "false")
    extra_applications(env)
  end

  # dev, test and custom envs …
  defp extra_applications(env) when is_atom(env) do
    extra_applications("true")
  end

  defp extra_applications("true"), do: [:logger, :runtime_tools, :google_maps, :os_mon, :wx, :observer]
  defp extra_applications(_env), do: [:logger, :runtime_tools, :google_maps, :os_mon]

In both ways you don’t have to change the way you generate releases, but in case you want a prod env with wx run:

$ MIX_ENV="prod" MY_PROJECT_USE_WX="true" iex -S mix phx.server
# or 
$ MY_PROJECT_USE_WX="true" iex -S mix phx.gen.release
2 Likes
3

Oh, damn, I totally forgot about using Mix.env() here, kinda dumb from my part since I use it already in other parts of my mix.exs haha :sweat_smile:.

Thanks for reminding me of that, worked like a charm :smiley:

1 Like
4

Not really, it’s not something every developer write on their own often enough to remember. There are lots of simple aspects of Erlang and Elixir that many developers are not aware of or just don’t remember. Fixing a bug in a good quality code is usually simple as you just have to create a minimal reproduction code, sometimes check the docs and that’s how you remind things.

This code is generated from mix phx.new task, so it’s not your fault you forget about it. Nobody is responsible to remember all functions. Since we talk in public topic it’s also worth to remind others that in configuration files they should use config_env (available after importing Config module) instead as mix application does not have to be available in every prod server.

2 Likes