我熟悉神器库，例如Artifactory，Maven＆amp;关系。
Berkshelf-API / Chef Supermarket与上述Artifact Repositories的不同之处是什么？
乍一看，它们似乎是现有工件存储库中的复制功能（不变性，传递依赖性解析等）。
澄清：这不是一个基于意见的问题，我正在寻找技术原因为什么Berkshelf-API / Chef Supermarket用于Chef Cookbooks而不是其他典型的工件库。
答案 0 :(得分：2)
tl; dr - Berkshelf-API＆amp;厨师超市是Berkshelf用于下载食谱依赖的东西。他们为Berkshelf提供了一个特殊格式的.JSON文档，用于确定烹饪书的依赖性。我没有找到为什么无法修改其他工件存储库以返回类似格式的.JSON文档的原因，但据我所知，目前都没有。
Berkshelf-API：“一个服务器，它从各种来源索引食谱并通过REST API托管它”
事实上，Chef Supermarket使用了Berkshelf-API。
您可以通过将“/ universe”附加到网址（https://supermarket.getchef.com/universe）来手动从超市中提取菜单列表。
当Berkshelf用于解析依赖关系时（使用'berks install'或'berks update'），它会查找源条目（通常是菜谱Berksfile顶部的“source”https://supermarket.getchef.com“'）。
Berksfile在源条目下方也有“元数据”。这会加载cookbook metadata.rb文件中列出的cookbook依赖项。这些可以被Berksfile中“元数据”条目下列出的cookbook依赖项覆盖。
然后，Berkshelf开始从源条目（在这种情况下是超市）下载cookbook依赖项。但是，Berkshelf不会递归加载依赖项的metadata.rb或Berkshelf文件。
例如：如果Foo依赖于依赖Baz的Bar
Foo =＆gt; Bar =＆gt;巴兹
Foo将在metadata.rb或Berksfile中指示Bar依赖项。
Bar将在metadata.rb或Berksfile中指示Baz依赖项。
但是，Berkshelf不会通过阅读Bar的metadata.rb或Berksfile来确定Bar（在本例中为Baz）的依赖关系。它通过使用从调用源条目返回的Berkshelf-API的版本化烹饪书的缓存列表来确定Bar的依赖关系。
私有Berkshelf-API服务器可以设置多个端点指向不同的cookbook存储库（另一个Berkshelf-API服务器或Chef服务器）。
因此，常见的用法是私有Berkshelf-API服务器，指向私有厨师服务器（存储非公共烹饪书）和厨师超市服务器（存储公共烹饪书）。