因此,假设我有一个钢筋应用程序结构,并且在deps文件夹中,我有很多依赖关系,有些是库应用程序,有些是需要启动的应用程序。我通常这样做:

start(_Type, _Args) ->
   code:add_path("../deps/depapp/ebin"),
   {ok, _} = application:ensure_all_started(depapp),


这是在开发环境中正确的方法吗?生产中怎么样?

最佳答案

您使用的方法不一定是错误的方法,但可能会暴露一些问题。例如,通过这种方式,您无法启动必须在应用程序之前启动的相关应用程序。

因此,对于loadingstarting依赖的OTP应用程序或库,还有其他选择。

1)使用erl命令行标志:

erl -pa ebin deps/*/ebing -s your_dep_app start -s your_app start


2)使用软件包管理器进行处理:

例如,作为包管理器的Rebar可以为您处理。您需要在rebar.config中指定应用程序依赖项,然后为Rebar2发出rebar get-deps或为Rebar3发出rebar3 compile。以下是Rebar3的示例配置文件的摘要:

{deps,[
  %% Packages
  rebar,
  {rebar,"1.0.0"},
  {rebar, {pkg, rebar_fork}}, % rebar app under a different pkg name
  {rebar, "1.0.0", {pkg, rebar_fork}},
  %% Source Dependencies
  {rebar, {git, "git://github.com/erlang/rebar3.git"}},
  {rebar, {git, "http://github.com/erlang/rebar3.git"}}]}.


有关Rebar依赖关系管理器的更多信息,请查看this链接。

同样,对于使用Rebar启动或加载它们,您可以释放并让Rebar启动或加载它们。以下是用于发布的示例钢筋配置文件的摘要:

{relx, [
    {release,
    {your_app, "0.1.0"},
        [your_dep_app_1,
         {your_dep_app_2, load}]}]}.


此配置加载并启动your_dep_app_1,但仅加载your_dep_app_2。有关Rebar版本管理器的更多信息,请查看this链接。

08-25 18:30