[erlang-questions] New .app option runtime_dependencies
Kenneth Lundin
kenneth.lundin@REDACTED
Tue Apr 15 17:23:29 CEST 2014
On Tue, Apr 15, 2014 at 4:07 PM, Tristan Sloughter <
tristan.sloughter@REDACTED> wrote:
> 2 questions regarding the new runtime_dependencies option in 17.0 .app
> files.
>
> 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, []},
> {runtime_dependencies,
> ["wx-1.2","stdlib-2.0","runtime_tools-1.8.14",
> "kernel-3.0","inets-5.10","et-1.5",
> "erts-6.0"]}]}.
>
> 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 are
> 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 tuple
> 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
> (https://github.com/erlware/relx) since currently the libs copied for a
> release that includes something like observer will not include necessary
> dependencies.
>
> Oh, one more thing, I don't understand what this sentence is saying, "In
> the case such optional dependencies exist, these are specified and
> documented in the corresponding "App" documentation of the specific
> application." (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
> tristan.sloughter@REDACTED
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
/Regards Kenneth Erlang/OTP Ericsson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140415/d23e1aec/attachment.htm>
More information about the erlang-questions
mailing list