Rebar3 功能介绍

Rebar3带有许多新的和改进的功能。在接下来的几周内，我将在这里发布博文以介绍其中的一些功能。

本地安装和升级

Rebar 是一个 escript 包，这对其易用性来说是非常重要的，主要是因为它们让 Erlang 用户可以将单个文件作为可执行文件，而不管底层的 Erlang 安装如何，甚至可以提交到项目的存储库。

所以，rebar3 也是一个脚本。可以从 s3 下载预构建的 escripts：

$ wget https://s3.amazonaws.com/rebar3/rebar3

或clone并bootstrap git repo：

$ git clone https://github.com/rebar/rebar3.git
$ cd rebar3
$ ./bootstrap

但是，escripts 确实有其缺点。它们启动速度较慢，依赖于旧的 Erlang io 服务器，运行 shell脚本rebar3 shell的行为与erl不完全相同，并且可能导致 repos 将 escript 与代码一起存储，但却从不升级它。

因此，在 rebar3 中，我们引入了提取 escript 存档以及运行脚本的功能~/.cache/rebar3/，以及一个将从 s3 获取 rebar3 的最新 escript 版本并执行相同操作的命令。

该install命令将位于提供程序命名空间下，最初它位于 命名空间下unstable，该命名空间用于在不久的将来可能会更改并且尚未被认为是稳定的实验性功能，但现在位于local命名空间中：

$ ./rebar3 local install
===> Extracting rebar3 libs to $HOME/.cache/rebar3/lib...
===> Writing rebar3 run script $HOME/.cache/rebar3/bin/rebar3...
===> Add to $PATH for use: export PATH=$HOME/.cache/rebar3/bin:$PATH

按照说明将 rebar3 bin 目录添加到您的$PATH中，或者添加到shell的配置文件~/.bashrc或~/.zshrc中.

要升级 rebar3 使用rebar3 local upgrade它将获取最新的 escript 并提取它：

$ rebar3 local upgrade

我们希望这种安装、升级和运行 rebar3 的新方法能让人们在项目存储库中不再捆绑 rebar3，解决 rebar3 和替代 Erlang 构建工具之间的任何编译速度差异，并帮助每个人了解最新功能和错误修复。

依赖关系树

rebar3 tree是一个新命令，允许用户查看每个传递依赖项中提取的依赖项。这对于 rebar3 的“first wins”依赖解决策略特别有用。

感谢Heinz N. Gies推动此功能，灵感来自leiningen的命令lein deps :tree。

例如，我克隆了chef-server并在src/oc_erchef目录下构建oc_erchef. 它是独一无二的，因为它既在src/中有顶级应用程序oc_erchef，也在apps/有其他项目应用程序。

此外，我还添加了_checkouts/erlware_commons以显示checkout dependencies（链接到 under 的应用程序），将其移动到顶层并标记为(checkout app)。并将lager切换到hex package dependency，其余的是git sourced dependencies。

$ rebar3 tree
├─ chef_db─12.1.2-6047c67 (project app)
├─ chef_index─12.1.2-6047c67 (project app)
├─ chef_objects─12.1.2-6047c67 (project app)
├─ chef_test─12.1.2-6047c67 (project app)
├─ depsolver─12.1.2-6047c67 (project app)
├─ erlware_commons─0.16.0 (checkout app)
├─ oc_chef_authz─12.1.2-6047c67 (project app)
├─ oc_chef_wm─12.1.2-6047c67 (project app)
└─ oc_erchef─12.1.2-6047c67 (project app)
   ├─ bcrypt─0.0.0+build.87.ref085eb59 (git repo)
   ├─ chef_authn─0.0.0+build.86.refe7850d0 (git repo)
   ├─ darklaunch─0.0.0+build.72.ref05881cb (git repo)
   │  └─ meck─0.8.3 (git repo)
   ├─ efast_xs─0.1.0 (git repo)
   ├─ ej─0.0.0+build.87.ref132a9a3 (git repo)
   ├─ envy─0.0.0+build.38.ref954c87a (git repo)
   ├─ eper─0.90.0 (git repo)
   ├─ folsom─0.0.0+build.335.ref38e2cce (git repo)
   │  └─ bear─0.0.0+build.32.ref1192345 (git repo)
   ├─ folsom_graphite─0.0.0+build.41.refd4ce9bf (git repo)
   ├─ gen_bunny─0.1 (git repo)
   │  ├─ amqp_client─0.0.0 (git repo)
   │  └─ rabbit_common─0.0.0 (git repo)
   │     └─ gen_server2─1.0.0 (git repo)
   ├─ ibrowse─4.0.1.1 (git repo)
   ├─ jiffy─0.0.0+build.131.reff661ee9 (git repo)
   ├─ lager─2.1.1 (hex package)
   │  └─ goldrush─0.1.6 (hex package)
   ├─ mini_s3─0.0.1 (git repo)
   ├─ mixer─0.1.1 (git repo)
   ├─ neotoma─0.0.0+build.125.ref760928e (git repo)
   ├─ opscoderl_folsom─0.0.1 (git repo)
   ├─ opscoderl_httpc─0.0.1 (git repo)
   ├─ opscoderl_wm─0.0.1 (git repo)
   │  └─ webmachine─0.0.0+build.526.ref7677c24 (git repo)
   │     └─ mochiweb─2.9.0 (git repo)
   ├─ pooler─0.0.0+build.159.ref7bb8ab8 (git repo)
   ├─ sqerl─1.0.0 (git repo)
   │  └─ epgsql─3.1.0 (git repo)
   ├─ stats_hero─0.0.0+build.73.refff00041 (git repo)
   │  └─ edown─0.2.4+build.66.ref30a9f78 (git repo)
   ├─ sync─0.1.3 (git repo)
   └─ uuid─1.3.2 (git repo)
      └─ quickrand─1.3.2 (git repo)

Overrides

当rebar.config中的依赖项有导致出现问题的设置时，您会怎么做？也许它包括在一般情况下不需要的依赖项，例如meckor edown。或者它可能设置了不准确的所需 OTP 版本并且您想要删除它。或者应用程序可能包含需要编译并依赖于 rebar2 的端口编译器的 C 代码。这些问题通常会导致项目分叉，这对任何人都不利，因此在 rebar3 中我们添加了一个名为overrides.

覆盖允许rebar.config比依赖项更高级别的任何内容替换或添加到较低级别的所有或单个应用程序的配置。

覆盖的类型规范如下所示：

{overrides, [{add, atom(), [{atom(), any()]}
             | {override, atom(), [{atom(), any()]},
             | {override, [{atom(), any()]} 
            ]}.

Basho的bitcask应用程序配置为使用 rebar2 构建，但用户无需分叉项目并修补配置，只需将以下覆盖部分添加到他们的rebar.config：

{overrides, 
  [
    {override, bitcask,
      [{deps, []},
       {plugins, [pc]},
       {artifacts, ["priv/bitcask.so"]},
       {provider_hooks, [{post, 
                          [{compile, {pc, compile}},
                           {clean, {pc, clean}}]
                         }]}
      ]
    }
  ]
}.

这些覆盖用于bitcask将其deps条目替换为空列表，这将删除meck仅在运行测试时才需要的依赖项和不需要的cuttlefish依赖项。另外，由于 rebar3 中删除了端口编译器功能，因此必须添加端口编译器插件并将其compile挂接clean到provider_hooks.

Profiles

配置文件可以用任何原子命名，可以将新项目添加到配置中，或者为现有元素添加新选项，并且多个配置文件可以自己组合。

两个特殊配置文件是default和global。default是所有运行的配置文件，输出将转到_build/default/，除非除 . 之外还指定了另一个default。当多个配置文件一起使用时，输出目录是连接在一起的配置文件+，例如 runningrebar3 as test,prod <task>会产生_build/test+prod/，但是在该运行中使用的配置文件的实际组合是default,test,prod，在输出default中总是从开头删除，除非它是唯一的配置文件利用。

另一个关于配置文件如何决定输出写入位置的特殊情况global总是引用~/.cache/rebar3/.

提供者可以default使用. 附带的四个提供程序指定了一个配置文件：、use和uses 。{profiles, [atom()]}providers:create/1rebar3eunitctcovertestedocdocs

配置文件使用示例可以帮助您了解如何在项目中使用它们。

{profiles, 
  [{test, [{deps,
            [
             meck,
             {eunit_formatters, {git, "git://github.com/seancribbs/eunit_formatters", {branch, "master"}}}
            ]},

            {eunit_opts, [
              no_tty,
              {report, {eunit_progress, [colored, profile]}}
             ]}
           ]
},
....

rebar2 中的另一个常见依赖项将包含在主依赖项列表中，因此即使在用作依赖项时也会被获取edown。使用运行的docs配置文件可以通过在配置文件下edoc移动来解决edown：

{profiles, [{docs, 
            [{deps, [
              {edown, {git, "git://github.com/uwiger/edown.git", {branch, "master"}}}
             ]}]
           }]
}.

dev_mode开发版本时，使用 relx并将其设置include_erts为 false很有用。但是在为生产构建版本时，您会想要相反的结果。在这种情况下，与测试和文档不同，需要指定要运行命令的配置文件。运行rebar3 release将默认运行，因此使用dev_mode为true 和include_erts为false，同时rebar3 as prod release从prod配置文件中提取设置，使dev_mode为false 和include_erts为true。

{relx, [...
        {dev_mode, true},
        {include_erts, false},
        ...
       ]}.

{profiles,
[{prod, [{relx, [
{dev_mode, false},
{include_erts, true}
]
}]
},

该global配置文件特别用于用户在其个人中定义的插件rebar.config。例如，我运行rebar3 as global plugins upgrade以升级我在~/.config/rebar3/rebar.config中配置的两个插件：

{plugins, [rebar3_hex, rebar3_run]}.

配置文件是 rebar 配置的重要补充，可简化开发和依赖关系管理。如果要成为一名优秀的 Erlang 公民，请将您的依赖项分离到适当的配置文件中，那些依赖您的应用程序的人会很感激。