語言/平臺/構建無關依賴關係管理器

Question

我需要一個不受特定語言或構建系統束縛的依賴關係管理器。我研究過幾種優秀的工具（Gradle，Bazel，Hunter，Biicode，Conan等），但都沒有滿足我的要求（見下文）。我也使用過Git Submodules和Mercurial Subrepos。

我的需求以及在presentation由丹尼爾·普法伊費爾在會C++ 2014中描述總結這種依賴性工具的目標（討論@ 18：55所鏈接的視頻的）：

• 不只是一個包經理
• 支持預建或源依賴性
• 可以下載或在本地找到 - 沒有不必要的下載
• 獲取使用各種方法（即下載，或VCS克隆，等）
• 集成與系統安裝程序 - 可以檢查LIB安裝
• 無需以任何方式
• 無需適應構建系統
• 跨平臺

適應源代碼

進一步的要求或說明我要補充：

• 適合第三方和/或版本化的依賴性，而且還能夠指定的非版本化和/或共同開發的依賴關係（可能由git/mercurial hash或tag指定）。
• 提供了一種機制來覆蓋指定的獲取行爲以使用我選擇的一些替代依賴項版本。
• 無需手動設置依賴庫。我並不反對中央依賴位置作爲避免冗餘或循環依賴的方法。但是，我們需要克隆repo並執行一些調用依賴關係管理器並構建所有內容的頂級構建腳本。
• 儘管我不需要修改我的構建系統，但顯然，某些頂級構建必須使用依賴關係管理器，然後將這些依賴關係提供給各個構建。該要求意味着個人版本不應該知道依賴關係管理器。例如，如果使用CMake作爲C++包，我不需要修改它的CMakeLists.txt來使特殊的函數調用來定位依賴關係。相反，頂層構建管理器應調用依賴管理器來檢索依賴關係，然後提供CMake以傳統方式（即find_package或add_subdirectory）使用的參數。換句話說，我應該始終可以選擇手動完成頂層構建和依賴管理器的工作，而單個構建不應該知道其中的差異。

尼斯到有：

• 詢問依賴管理後的，其實找一個地方依賴放置的方法。這將允許我創建VCS掛鉤來自動更新共同開發的源代碼repo依賴關係的依賴元數據中的散列。 （就像子模塊或subrepos一樣）。

Answer 1

在徹底搜索可用技術後，與各種語言的軟件包管理器（即npm）進行比較，甚至在我自己的依賴管理器工具上運行，我已定居在柯南上。在深入科南之後，我發現它滿足了我的大部分要求，並且易於擴展。

在研究柯南之前，我看到了BitBake作爲我尋找的模型。但是，它只是Linux，並且主要面向嵌入式Linux發行版。柯南已經基本相同的配方特點和BB是真正的跨平臺

這裏是我的要求，我發現柯南：

• 不只是一個包管理器
• 支持預建或源依賴性

柯南支持經典的釋放或開發的依賴，也可以讓你的網絡源。如果具有特定配置/設置的二進制文件不存在於註冊中心（或Conan的說法「存儲庫」）中，則會從源代碼構建二進制文件。如果LIB安裝

柯南維護本地註冊表緩存可以檢查 -

• 可以下載或在本地找到 - 沒有不必要的下載
• 集成與系統安裝。因此，發生共享依賴關係的獨立項目不需要重新進行昂貴的下載和構建。

  柯南不會阻止你找到系統包而不是聲明的依賴關係。如果您編寫構建腳本以通過前綴路徑，則可以即時更改各個依賴項的路徑。

  • 獲取使用多種方法（即下載或VCS克隆等）

  實施配方的source函數給出了一個依賴如何被取出的完全控制。柯南支持做下載/克隆源代碼的食譜，或者可以「快照」源代碼，將其與食譜本身打包在一起。

  • 無需適應的源代碼以任何方式
  • 無需適應構建系統

  柯南支持各種發電機組通過您所選擇的構建系統，使依賴耗材。來自特定構建系統的不可知論是柯南真正的勝利，並最終導致Bazel，Buckaroo等人的依賴管理繁瑣。

  • 跨平臺的Python 。檢查。

  • 適用於第三方和/或版本化的依賴項，但也能夠指定非版本化和/或共同開發的依賴項（可能由git/mercurial hash或tag指定）。

  內置在考慮semver，但可以使用任何字符串標識符版本。另外還有user和channel作爲軟件包版本的命名空間。

  • 提供一種機制覆蓋指定抓取行爲，以便使用我選擇的一些替代的依賴版本。

  您可以防止不包括它在install取命令特定的依賴。或者您可以修改或覆蓋生成的前綴信息以指向磁盤上的其他位置。

  • 無需手動設置依賴庫。我並不反對中央依賴位置作爲避免冗餘或循環依賴的方法。但是，我們需要克隆repo並執行一些調用依賴關係管理器並構建所有內容的頂級構建腳本。 儘管我不需要修改我的構建系統，但顯然，某些頂級構建必須使用依賴關係管理器，然後將這些依賴關係提供給各個構建。這個需求意味着單個構建不應該意識到依賴關係管理器。例如，如果使用CMake作爲C++包，我不需要修改它的CMakeLists.txt來進行特殊的函數調用來查找依賴關係。相反，頂層構建管理器應調用依賴管理器來檢索依賴關係，然後提供CMake以傳統方式（即find_package或add_subdirectory）使用的參數。換句話說，我應該始終可以選擇手動完成頂層構建和依賴管理器的工作，而單個構建不應該知道其中的差異。

  柯南緩存本地註冊表中的依賴項。這是無縫的。在Conan的文檔中您將看到的規範模式是在構建腳本中添加一些Conan特定的調用，但這可以避免。再一次，如果您將構建腳本寫入消費者前綴路徑和/或輸入參數，則可以傳遞信息並根本不使用柯南。我認爲柯南CMake發電機可以使用一點工作來使這更優雅。作爲一種倒退，柯南讓我寫自己的發電機。

  • 詢問依賴管理後的，其實找一個地方依賴放置的方法。這將允許我創建VCS掛鉤來自動更新共同開發的源代碼repo依賴關係的依賴元數據中的散列。 （就像子模塊或subrepos一樣）。

  發電機指向這些位置。藉助Python的全部功能，您可以根據自己的內容對其進行自定義。

  目前共同開發的依賴項目對我來說是最大的問題。意思是說，我不知道柯南是否有開箱即用的功能來讓跟蹤提交變得簡單，但我相信這些掛鉤可以添加這個定製。

  其他的事情我在柯南發現：

  • 柯南提供下載或建立我在開發過程中需要的工具鏈的能力。它使用Python virtualenv來輕鬆啓用/禁用這些自定義環境，而不會污染我的系統安裝。