Why do we use application function in mix.exs?

Questions / Help
, ,
1

Background

I am trying to understand the purpose of the application function in the mix.exs files we get, but I have some questions that need clarification.

Following is an example of said function:

def application do
    [
      extra_applications: [:logger],
      mod: {FootbalInterface.Application, [http_port: 8080]}
    ]
  end

Questions

  1. Why do we need extra_applications? I understand that in the past we needed to tell mix which applications to run on startup before our app was running. But these days, mix is pretty smart and it starts all needed applications before starting our own app. So why do we still have this value for Elixir 1.9? I think even :logger starts automatically so why do we have it there?

  2. Do we need mod? I understand this tells mix the starting parameters for my app, but if I can simply use Application.get_env in the files, then why do I need this? Will this allow me to start the application by passing values into the command line, like mix -S iex --args http_port: 4000 or something like that?

2

The return value of the application/0 callback in a Mix.Project is used to build the actual OTP-application manifest.

Whether or not you need :extra_applications and :mod clearly depends on your use case.

:extra_applications is required once you want to embed and start applications into your release that are part of elixir or erlang distribution. If you do not specify them, they won’t get embedded. They are added to the usually infered (since 1.4) :applications key, which you shouldn’t set anymore since inference is in place.

:mod is required if you want an “active” application that has its own supervision tree. It actually tells the runtime how to start and stop the application.

3 Likes
3

:logger IIRC starts “automatically” only in development (and in production it will start due to fact that this is commonly present in deps). However there are other applications that can be present in application and aren’t started by default, :inet is one of them (it is automatically started in Phoenix as one of it’s deps include that app).

About :mod it say which is the “launching point” module in our application. Otherwise how would :init supervisor know where is the main launching point of our application? There is no “convention” there.

2 Likes
4

There are also a few more keys, which can be present in the returned data of application/0: https://hexdocs.pm/mix/Mix.Tasks.Compile.App.html

2 Likes
5

So, if I set extra_applications: [] and my application (which, let’s assume, has no deps) has a require Logger somewhere launches, will it crash?

I understand that If my app doesn’t have a require Logger in its code, I can just remove that array and everything will work fine, independent of its dependencies. Is this correct?

Like :runtime_tools, right?
So what I take from this is that in Elixir 1.9, we still have :logger in the array of extra applications because it is assumed we will use it somewhere in our app via require Logger. Would this assessment make sense?

That makes sense. But why would someone bother passing starting parameters via mod instead of just using Application.get_env in the application.ex file?

Is there a special way to launch an app I am not aware of?

6

No unless it will try to send message to the Logger process (so any logging will not work).

Probably yes as any dependency that uses Logger should handle that for you.

Exactly.

Yes, this is done for user convenience. However I think that in future we should move Logger modules to Elixir stdlib and make :logger dummy application as we should move to Erlang’s :logger (which is in :kernel which is always started).

I cannot find any, but I haven’t reviewed it more. Maybe there is option to overwrite such configuration or other stuff. Passing arguments via :mod can also be useful in case of phase usages.

Think about it like CLI options passed in systemd service file vs configuration file for such application.

2 Likes