[erlang-questions] New .app option runtime_dependencies

Tristan Sloughter <>
Tue Apr 15 17:34:07 CEST 2014

Right, relx generated shell scripts start the release in embedded mode,
so we'll need to either lay the burden on the user to list deps of apps
like observer or use runtime_dependencies. This isn't an issue with
library deps listed in applications since they don't have starts.

So having runtime_dependencies that aren't library apps but you can
list as deps and know they will only be in the path (or loaded in the
case of our relx generated releases that are run in embedded mode) is

This is something that can be useful, which is why I hope it is open to
use cases and feedback outside of the OTP team's use.

Tristan Sloughter

On Tue, Apr 15, 2014, at 08:23 AM, Kenneth Lundin wrote:

On Tue, Apr 15, 2014 at 4:07 PM, Tristan Sloughter
<[1]> wrote:

2 questions regarding the new runtime_dependencies option in 17.0 .app


First, the docs leave a lot to the imagination, if we look at the new

.app file for observer:

The documentation is sparse (on purpose) because this is a format and
data that is not really finished
or ready for broad usage yet. It is uesd by the OTP team to keep track
of version dependencies between
applications in order to know if a certain version of an application
can be installed and run together with
other applications on a specific system.

Note the big WARNING SIGNS,
I would not recommend that you invest a lot of time building tools that
use this information if you are not prepared that it can change any
time during OTP 17.x.

λ cat lib/observer-2.0/ebin/observer.app

{application, observer,

   [{description, "OBSERVER version 1"},

    {vsn, "2.0"},

    {modules, [....]},

    {registered, []},

    {applications, [kernel, stdlib]},

    {env, []},





How is a runtime_dependencies app different from one in the

'applications' key's values?

what is stated under the 'applications' key is start dependencies to
other applications (they must be started before this application).

Are they only started if they are in

'applications' and if they only exist in runtime_dependencies they

should simply be in the path or should they be loaded? Or is it only to

specify required version? In which case... why another entry and why

there apps in runtime_dependencies that aren't listed in applications.

the applications listed under the 'runtime_dependencies' are
applications that are needed in order to run
this particular application. I.e they will be called by this
application. It is also specifying that a certain version or higher is
needed of each application.
Nothing will be loaded or started because of this list.

Applications without processes don't need to be started but can still
be called.

If you try to make a release (a .rel file) where you include observer
and forget some of the other applications you will have something
incomplete which is likely to fail in runtime.
Depending on if you are running in embedded or interactive mode you
need the applications in the .rel file (ending up in the start script)
or in the code path where they are loaded on demand.

Next, will the OTP team work with the community on the format (I know

the type is subject to change, and think that is a good thing... a

like {wx, ">=1.2"} would make more sense in my opinion) and the actual

use of this key's values?

Yes there is room for improvements. We have already discussed solutions
like that and they might be added later on.

We are looking to see what to do for relx

([2]https://github.com/erlware/relx) since currently the libs copied
for a

release that includes something like observer will not include


Oh, one more thing, I don't understand what this sentence is saying,

the case such optional dependencies exist, these are specified and

documented in the corresponding "App" documentation of the specific

application." ([3]http://www.erlang.org/doc/man/app.html)

Today the format does not allow to specify optional
runtime_dependencies so these are listed under
the runtime_dependencies key but should be commented in the
documentation of the application.

Example of an optional dependency is for example if application A is
dependent on application B only if a certain option or configuration of
application A is used.
For example SNMP can use tables stored in Mnesia and is by this
optionally dependent on Mnesia since
SNMP can very well be used without tables stored in Mnesia and is thus
not always dependent on Mnesia it depends on what the user is doing
with SNMP. It would be good to have some format to express these kind
of dependencies as well.

Most of the runtime_dependencies we have in place are generated with
xref and then manually inspected
and occasionally a dependency is removed because it is just a debugging
or test dependency or a
dependency is added because it is a dynamic one (apply) that xref
cannot find.

There are still many open questions.


  Tristan Sloughter



erlang-questions mailing list



/Regards Kenneth Erlang/OTP Ericsson


1. mailto:
2. https://github.com/erlware/relx
3. http://www.erlang.org/doc/man/app.html
4. mailto:
5. mailto:
6. http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140415/87fa25dd/attachment.html>

More information about the erlang-questions mailing list