使用钢筋处理外部库答案

【问题标题】：Handling external libs with rebar使用钢筋处理外部库
【发布时间】：2011-07-27 12:04:19
【问题描述】：

我想在我的应用程序中使用一些库，例如 https://github.com/Panmind/erlang-ruby-marshal。该 repo 包含一个 src 目录，但没有 .app 文件（因为它不是应用程序），所以我不能使用 get-deps。

我尝试了另一种方法，在 sub_dirs 中添加 libs 目录并将 repo 添加为 git 子模块，但 rebar 不会编译它的任何文件。我猜 rebar 只编译 otp 应用程序，而不仅仅是不绑定到应用程序的 .erl 文件。

您如何管理这些依赖关系？我想避免将文件复制到我的应用程序目录，因为我认为它们不属于那里，而且我有点喜欢 git 子模块方法，它允许我跟踪我正在使用的 lib 版本。

【问题讨论】：

为什么不是应用程序？您可以拥有一个只是模块集合的应用程序（不使用{mod, ...} 选项）。
这很有趣，但是由于我是从现有存储库中提取的，因此没有 .app 文件。

标签： erlang dependency-management rebar

【解决方案1】：

最近的 rebar 支持 raw 依赖项选项。当此选项是特定的时，rebar 不需要依赖项具有标准 Erlang/OTP 布局，该布局假定存在“src/dependency_name.app.src”或“ebin/dependency_name.app”文件（请参阅更多详细信息@987654321 @)。

例如：

{deps, [
  {erlang_ruby_marshal, "",
    {git, "https://github.com/Panmind/erlang-ruby-marshal", {branch, master}},
    [raw]}
]}.

请注意，rebar 现在可以获取它，但它仍然无法编译它。正如其他评论者所指出的那样，这种依赖没有理由不应该有 .app 文件。我会分叉存储库并将.app 文件添加到其中。

【讨论】：

这似乎是一件很方便的事情。您是否考虑过向主线钢筋项目提交拉取请求？
@clofresh，是的，我仍然考虑这样做。这周我会试着找点时间来正确地实现它——它比我最初的琐碎复制粘贴需要更多的工作，需要进行 3 次编辑。
@clofresh，我重新审视了这个问题，并将新版本作为拉取请求提交：github.com/basho/rebar/pull/217 随意留下一些 cmets。这可能有助于更快地合并。
@clofresh，补丁终于被接受了。现在它是标准钢筋的一部分。

【解决方案2】：

This article 经历了创建应用程序和使用 rebar 发布的更大过程。

更具体地说，我认为rebar.config 中的这个选项可能是您正在寻找的。到目前为止，我发现的唯一方法是为每个应用程序设置一个条目：

{sub_dirs, ["libs/app1",
            "libs/app2",
            ...]}.

这需要更多的手动工作。不幸的是，rebar 仅围绕一个应用程序的概念进行了非常结构化，并且需要更好的支持来维护包含一堆同等价值的应用程序而不是单个应用程序的存储库。

【讨论】：

是的，我试过了，但是 rebar 不会编译 libs 目录中的任何 erl 文件。
确切地说，我添加了“libs/erlang-ruby-marshal”目录，其中包含 src 目录，但正如我所说，rebar 不会在其中编译任何内容。
想出了一种方法。在我看来，这并不完全令人满意，因为在添加、删除或重命名应用程序时需要人工干预。
我还需要一个 .app 文件，由于 git 子模块没有，所以这个方法行不通。
rebar 可与 OTP 兼容的应用程序一起使用，因此如果您的代码不符合 OTP 标准，那么使用 rebar 可能会不走运。

【解决方案3】：

如果您使用的是 Linux，您可以将所需模块作为硬链接添加到应用程序的 src 目录中。

这远非最佳，但我还没有找到更好的方法来做到这一点。

【讨论】：

【解决方案4】：

请 Agner 人员将其添加到他们的包管理系统中。在此过程中，他们将创建一个分叉并进行转换以使项目钢筋兼容。此外，原始维护者很可能会整合这些更改。

【讨论】：