何时使用erlang应用程序：start或included_applications和主管？

Question

我有一个Erlang应用程序，它在另一个应用程序的deps目录中有一个依赖项。

根据我的理解，我也可以;

a）通过调用application：start（some_other_app）启动我的依赖应用程序，启动应用程序并显示它在Observer中独立运行。

b）在我的.app文件中包含我的依赖应用程序{included_applications，[some_other_app]}，以便应用程序加载而不启动，然后从我自己的顶级主管启动包含的应用程序。这将再次启动包含的应用程序，并在Observer中显示其在我自己的监督层次结构下运行。

我的问题是我应该何时使用这两种方法？如果我使用选项“a”并且我的依赖应用程序退出将重新启动，或者我应该使用方法“b”，以便相应地监视我拥有的任何依赖项？

在旁注中，我使用Rebar打包和管理我的依赖项。

谢谢，

安迪。

Answer 1

你可能不应该做a）或b）

来自Learn You Some Erlang

请看章节：Included Applications

  

越来越多的人建议不要使用附带的应用程序   原因很简单：他们严重限制代码重用。这样想吧。   我们花了很多时间研究ppool的架构来实现它   所以任何人都可以使用它，拥有自己的游泳池并可以自由地做任何事情   他们想要它。如果我们将它推入一个包含的应用程序，   然后它不能再包含在这个VM上的任何其他应用程序中，   如果erlcount死了，那么ppool会被它取下来，毁了   任何想要使用ppool的第三方应用程序的工作。

     

由于这些原因，所包含的申请通常被排除在外   许多Erlang程序员的工具箱。我们将在下面看到   章，版本基本上可以帮助我们做同样的事情（以及更多）   更通用的方式。

在Release is the Word一章中，您可以了解如何将多个应用程序捆绑到一个版本中以及它们是如何启动的。

Answer 2

在您的应用程序描述符中声明您的依赖项是可行的方法，因此您应该在大多数情况下使用选项B.

应用程序控制器将确保在启动应用程序之前存在并启动所有依赖项（按顺序），如果这些依赖项以错误终止，也会使应用程序失败。此外，应用程序控制器将在需要时关闭所有内容。

除此之外，如果你选择选项A，当用应用程序启动应用程序时：start / 1，默认情况下你会得到一个临时应用程序，所以你应该使用application：start / 2，传递永久原子作为第二个参数。

编辑：在应用程序描述符中包含依赖项也有助于提高可见性，在不扫描源代码的情况下很容易知道您的deps。

Answer 3

我有一个类似的问题，你如何在erlang项目中包含依赖项，然后如何发布它们？

我得到了各种朋友和erlang邮件列表的帮助......在重新阅读了一些文档和更多的试错之后......我想出了一些东西。这很长，所以看看要点：

https://gist.github.com/3728780

-Todd