我正在尝试拥有一个管理我的环境的 git 存储库。我已经为特定任务编写了一组 lwrp。这些 lwrps 内部依赖于许多社区食谱。
我的每本食谱都有一个 Berksfile，我在其中指定依赖关系解析。在我的存储库的根文件夹中，我有一个主 Berksfile，其中列出了我想要从我的存储库中获得的所有食谱。
我现在想要的是，当我从根位置进行 berks 安装时，它应该获取我的说明书，然后解析它们以从每个说明书中找到单独的 berks 文件并解决所有依赖项。但是，它的行为并非如此。
有人对此有任何想法吗？这是 Berks 如何工作的常见场景吗？还是我遗漏了一些东西以致无法解决依赖关系？
提供更多信息：我的食谱有这个berksfile
source 'https://supermarket.chef.io'
cookbook 'apache_spark', '~> 1.2.12'
并且 apache spark 内部依赖于
cookbook 'monit', github: 'phlipper/chef-monit', tag: '1.5.2'
这是提到的问题的副本，但由于没有超级详细的答案，我将在此处添加更多内容。
如其他答案所述，Berksfile指令是“不可传递的”。食谱中的metadata.rb依赖是符号依赖，只是一个名称和一个版本约束，没有关于从哪里获取它的信息。与说明书一起使用的每个工具对如何处理这些符号依赖项都有不同的理解，例如，当您运行 a 时，berks install您可能会从超市或 GitHub 中提取依赖项，但当厨师客户端处理它们时，它会从厨师服务器获取所有内容。在符号依赖项与从何处获取它们之间保持这种分离允许许多工具共存。这Berksfile提供有关从何处下载特定说明书的附加数据，从符号依赖项中扩充或替换信息，但由于这些额外的指令不是说明书元数据的一部分，它们不能递归完成。
最大的问题是 Supermarket 是一个平面命名空间，因此只能有一本名为monit. 这导致许多人不在 Supermarket 上发布东西，而是通过 git 源指令依赖它们。这意味着depends "monit"不再像应有的那样清晰。这确实应该被视为未发布食谱的错误，但我理解人们不愿意重命名他们的食谱以正确发布它们。
通常的解决方法是从上游复制一些东西到你的新东西Berksfile中，或者在一个私人超市实例（或等效的厨师服务器组织）中创建一个孤立的食谱宇宙，在那里你只上传你想要的东西，然后这样做depends "monit"再次变得明确。