Skip to content

Commit e74701e

Browse files
author
José Valim
committed
Backport application docs improvements
1 parent 284a7d0 commit e74701e

File tree

1 file changed

+60
-16
lines changed

1 file changed

+60
-16
lines changed

lib/elixir/lib/application.ex

Lines changed: 60 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -9,17 +9,57 @@ defmodule Application do
99
Applications are defined with an application file named `APP.app` where
1010
`APP` is the application name, usually in `underscore_case`. The application
1111
file must reside in the same `ebin` directory as the compiled modules of the
12-
application.
13-
14-
In Elixir, Mix is responsible for compiling your source code and
15-
generating your application `.app` file. Furthermore, Mix is also
16-
responsible for configuring, starting and stopping your application
17-
and its dependencies. For this reason, this documentation will focus
18-
on the remaining aspects of your application: the application environment
19-
and the application callback module.
20-
21-
You can learn more about Mix generation of `.app` files by typing
22-
`mix help compile.app`.
12+
application. In Elixir, the Mix build tool is responsible for compiling your
13+
source code and generating your application `.app` file. You can learn more
14+
about the generation of `.app` files by typing `mix help compile.app`.
15+
16+
Once your application is compiled, running your system is a matter of starting
17+
your current application and its dependencies. Differently from other languages,
18+
Elixir does not have a `main` procedure that is responsible for starting your
19+
system. Instead, you start one or more applications, each with their own
20+
initialization and termination logic.
21+
22+
Starting an application is done via the "application module callback", which
23+
is a module that defines the `start/2` function. The `start/2` function should
24+
then start a supervisor, which is often called as the top-level supervisor, since
25+
it sits at the root of a potentially long supervision tree. When the system is
26+
shutting down, all applications shut down their top-level supervisor, which
27+
terminates children in the opposite order they are started.
28+
29+
We have mentioned the Mix build tool is responsible for compiling applications,
30+
but it is also capable of running applications. For example, `mix test`
31+
automatically starts your application dependencies and your application itself
32+
before your test runs. `mix run --no-halt` also boots your current project and
33+
can be used to start a long running system. See `mix help run`.
34+
35+
Developers can also use tools like [Distillery](https://github.com/bitwalker/distillery)
36+
that build **releases**. Releases are able to package all of your source code
37+
as well as the Erlang VM into a single directory. Releases also give you explicit
38+
control over how each application is started and in which order. They also provide
39+
a more streamlined mechanism for starting and stopping systems, debugging, logging,
40+
as well as system monitoring.
41+
42+
Finally, Elixir provides tools such as escripts and archives, which are
43+
different mechanisms for packaging your application. Those are typically used
44+
when tools must be shared between developers and not as deployment options.
45+
See `mix help archive.build` and `mix help escript.build` for more detail.
46+
47+
Shutting down a live system cleanly can be done by calling `System.stop/1`.
48+
It will shut down all applications in the opposite order they are started.
49+
Each application will then shutdown its top-level supervisor, if one is
50+
available, which then shuts down its children.
51+
52+
From Erlang/OTP 19.1, a SIGTERM from the operating system will automatically
53+
translate to `System.stop/0`. Erlang/OTP 20 gives user more explicit control
54+
over OS signals via the `:os.set_signal/2` function.
55+
56+
Applications also provide an "application environment", which is how
57+
applications are configured. The application environment can either be set
58+
statically, via a configuration file, or dynamically via `put_env/3` and
59+
friends.
60+
61+
Over the next sections, we will cover the "application environment" and
62+
the "application module callback" in more detail.
2363
2464
## Application environment
2565
@@ -40,9 +80,13 @@ defmodule Application do
4080
Application.get_env(:APP_NAME, :hello)
4181
#=> :world
4282
43-
It is also possible to put and delete values from the application value,
44-
including new values that are not defined in the environment file (although
45-
this should be avoided).
83+
Applications and dependencies in Mix projects are typically configured
84+
via the `config/config.exs` file. For example, someone using your
85+
application can configure the `:hello` key as follows:
86+
87+
config :APP_NAME, hello: :brand_new_world
88+
89+
It is also possible to configure applications dynamically via `put_env/3`.
4690
4791
Keep in mind that each application is responsible for its environment.
4892
Do not use the functions in this module for directly accessing or modifying
@@ -78,8 +122,8 @@ defmodule Application do
78122
79123
The `type` argument passed to `start/2` is usually `:normal` unless in a
80124
distributed setup where application takeovers and failovers are configured.
81-
This particular aspect of applications is explained in more detail in the
82-
OTP documentation:
125+
Distributed applications is beyond the scope of this documentation. For those
126+
interested on the topic, please access the OTP documentation:
83127
84128
* [`:application` module](http://www.erlang.org/doc/man/application.html)
85129
* [Applications – OTP Design Principles](http://www.erlang.org/doc/design_principles/applications.html)

0 commit comments

Comments
 (0)