4 Matching Annotations
  1. Jul 2020
    1. If the run-time dependencies were shared across all applications depending on the same rebar.config file,

      This sentence is straightforward but I only understood it just now.

      rebar.config can specify the dependencies of all the applications in the umbrella project, but they are not necessarily run-time dependencies. Also, the relx example from the rebar.config above shows how to include an app/lib (in this case, recon) in the final production release, even if it is not a run-time dependency.

      This guide also expands on it a paragraph below:

      The Rebar3 maintainers therefore just decided to keep a clear distinction between the applications that need fetching for the project to build or run (in rebar.config), and the run-time dependencies of each OTP application (in the .app file) which may be part of the default OTP install, and would therefore not be included in rebar.config. Other build tools in the ecosystem let you achieve similar results, but they default to including everything at run-time whereas Rebar3 asks of developers to always be specific in their intent.

    1. mark the workers as permanent or transient, so that if they fail they get restarted

      restart defines when a terminated child process must be restarted.

      • A permanent child process is always restarted.
      • A temporary child process is never restarted (even when the supervisor's restart strategy is rest_for_one or one_for_all and a sibling's death causes the temporary process to be terminated).
      • A transient child process is restarted only if it terminates abnormally, that is, with another exit reason than normal, shutdown, or {shutdown,Term}. https://erlang.org/doc/man/supervisor.html
  2. Jul 2019
  3. Mar 2017