我有一个 Erlang 应用程序，它在其 deps 目录中依赖于另一个应用程序。
据我了解，我可以；
a) 通过调用 application:start(some_other_app) 从我的包含应用程序启动我的依赖应用程序，该应用程序启动应用程序并显示它在 Observer 中独立运行。
b) 使用 {included_applications, [some_other_app]} 将我的依赖应用程序包含在我的 .app 文件中，以便加载应用程序而不启动，然后从我自己的顶级主管启动包含的应用程序。这再次启动了包含的应用程序，并显示它在 Observer 中我自己的监督层次结构下运行。
我的问题是我什么时候应该使用这两种方法？如果我使用选项“a”并且我的依赖应用程序退出，它将重新启动还是应该使用方法“b”以便相应地监视我的任何依赖关系？
在旁注中，我使用 Rebar 来打包和管理我的依赖项。
谢谢，
安迪。
您可能不应该这样做 a) 或 b)
查看章节：包含的应用程序
越来越多的建议不要使用包含的应用程序，原因很简单：它们严重限制了代码重用。这样想吧。我们花了很多时间研究 ppool 的架构，以便任何人都可以使用它，拥有自己的池，并可以自由地用它做任何他们想做的事情。如果我们将它推送到一个包含的应用程序中，那么它就不能再包含在这个 VM 上的任何其他应用程序中，如果 erlcount 死了，那么 ppool 将被删除，破坏任何想要的第三方应用程序的工作使用 ppool。
由于这些原因，包含的应用程序通常被排除在许多 Erlang 程序员的工具箱之外。正如我们将在下一章中看到的，发布基本上可以帮助我们以更通用的方式做同样的事情（甚至更多）。
在Release is the Word一章中，您可以了解如何将多个应用程序捆绑到一个版本中以及如何启动它们。
在您的应用程序描述符中声明您的依赖项是可行的方法，因此您应该在大多数情况下使用选项 B。
应用程序控制器将确保您的所有依赖项都存在并在启动应用程序之前（按顺序）启动，并且如果这些依赖项因错误而终止，也会使您的应用程序失败。此外，应用程序控制器将在需要时关闭所有内容。
除此之外，如果您选择选项 A，当使用 application:start/1 启动应用程序时，默认情况下会获得一个临时应用程序，因此您应该使用 application:start/2，将永久原子作为第二个参数传递。
编辑：在应用程序描述符中包含依赖项也有助于可见性，无需扫描源代码即可轻松了解您的部门。
我有一个类似的问题，如何在 erlang 项目中包含依赖项，然后如何发布它们？
我得到了各种朋友的帮助，以及 erlang 邮件列表……在重新阅读了一些文档和更多的试验和错误之后……我想出了一些东西。它很长，所以请查看要点：
https://gist.github.com/3728780
-托德