Fl4m3Ph03n1x
Why do we use application function in mix.exs?
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
-
Why do we need
extra_applications? I understand that in the past we needed to tellmixwhich applications to run on startup before our app was running. But these days,mixis 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:loggerstarts automatically so why do we have it there? -
Do we need
mod? I understand this tells mix the starting parameters for my app, but if I can simply useApplication.get_envin the files, then why do I need this? Will this allow me to start the application by passing values into the command line, likemix -S iex --args http_port: 4000or something like that?
Marked As Solved
hauleth
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.
Also Liked
NobbZ
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.
hauleth
: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.
LostKobrakai
There are also a few more keys, which can be present in the returned data of application/0: mix compile.app — Mix v1.20.2
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Build Elixir applications with speed and confidence.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Develop your skills with books, videos, and courses.
Enabling companies to succeed by building software people love.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"