對許多人來說，依賴關係是一場噩夢。一些人甚至認為它們是技術債務。管理你的軟體的庫列表是一種可怕的體驗。自動更新依賴項?-這聽起來像是在說胡話。
首先，我們需要清楚地了解一些有關依賴關係的知識: 依賴關係有兩種型別。donald stuff幾年前寫的關於這個主題的文章比我要寫的都好。簡單一點來說，它們是依賴於外部**的兩種型別的**包:應用程式和庫。
庫依賴
python庫應該以一種通用的方式來指定它們的依賴關係。乙個庫不應該要求requests 2.1.5:這沒有意義。如果每個庫都需要不同版本的requests，我們就不能同時使用它們。
庫需要根據版本號的範圍來宣告依賴關係。要求請求requests>=2是正確的。如果你知道requests2.x不適用於該庫，那麼要求 requests>=1,<2 也是正確的。你的版本範圍定義正在解決的問題是你的**和依賴項之間的api相容性問題———沒有其他問題。這是庫盡可能使用語義版本控制的乙個很好的理由。
因此，依賴關係應該寫在setup.py中,類似於:
這樣，任何應用程式都可以輕鬆地使用庫並與其他應用程式共存。
應用程式依賴關係
應用程式只是庫的一種特殊情況。它們不打算被其他應用程式庫重用(匯入)——儘管在實踐中沒有什麼可以阻止它。
最後，這意味著你應該像為乙個庫指定依賴關係一樣來在應用程式的setup.py中指定依賴關係。
其主要區別在於，乙個應用程式通常部署在生產環境中以提供其服務。部署需要是可復用的。為此，你不能僅僅依賴於setup.py:因為請求的依賴關係範圍太寬。在重新部署應用程式時，你希望隨時都可以隨意更改版本。
因此，你需要乙個不同的版本管理機制來處理部署，而不僅僅是setup.py。
pipenv在其文件中有一節很好地總結了這一點。它將依賴關係型別劃分為抽象依賴項和具體依賴項: 抽象依賴項基於範圍(例如 庫)，而具體依賴項是用精確的版本(例如應用程式部署)指定的——正如我們在這裡看到的。
處理部署
requirements.txt檔案長期以來一直被用來解決應用程式部署的可復用性問題。它的格式通常是這樣的:
每個庫都將自己指定為微版本。這確保你的每個部署都將安裝相同版本的依賴項。使用requirements.txt是乙個簡單的解決方案，也是實現可復用部署的第一步。然而，這還不夠。
實際上，雖然你可以指定你想要的requests的版本，但是如果requests依賴於urllib3，那麼這將會使pip安裝urllib 2.1或urllib 2.2。你無法知道哪乙個會被安裝，這並不能使你的部署100%可重用。
當然，你可以在你的requirements.txt中複製所有的requests依賴項，但那將是瘋狂的做法!
乙個應用程式依賴關係樹有時可能非常深入和複雜。
有各種各樣的技巧可以用來修復這個限制，但是真正的救星是pipenv和poetry。它們解決這個問題的方法類似於其他程式語言中的許多包管理器。它們生成乙個鎖檔案，其中包含所有已安裝的依賴項(以及它們自己的依賴項等)的列表和版本號。這可以確保部署是100%可復用的。
請檢視它們的文件，了解如何設定和使用它們!
處理依賴項更新
現在，你已經有了鎖檔案，它可以確保你的部署在短時間內是可復用的，那麼你就有了另乙個問題。你如何確保你的依賴項是最新的?這是乙個真正的安全問題，而且保持版本落後的話，你可能也會錯過bug修復和進行優化的機會。
如果你的專案託管在github上，dependabot是解決這個問題的乙個很好的解決方案。當你的鎖檔案中列出的庫的乙個新版本可用時，在儲存庫上啟用此應用程式將會自動創合併請求。例如，如果你已經使用redis 3.3.6部署了你的應用程式，當新版本redis 3.3.7發布時，dependabot將會建立乙個更新到redis 3.3.7的合併請求。此外，dependabot還支援requirements.txt、 pipenv和poetry!
自動部署更新
快要成功了。你有乙個機械人，它讓你知道你的專案需要的乙個庫的新版本是可用的。
一旦建立了合併請求，你的持續整合系統就會啟動、部署你的專案並執行測試。如果一切正常，你的合併請求就可以被合併了。但是在這個過程中真的需要你參與嗎?
除非你個人特別反感某個特定的版本號——「天哪，我討厭以3結尾的版本。遇見它總是運氣不好。——或者除非你沒有自動化測試，否則你，人類，是無用的。這個合併完全可以是自動化的。
這就是mergify發揮作用的地方。mergify是乙個github應用程式，它允許你定義關於如何合併合併請求的精確規則。下面是我在每個專案中都使用的乙個規則:
當規則完全匹配時，mergify會進行報告。
一旦你的持續整合系統通過，mergify就會為你合併該合併請求。
然後，你就可以自動觸發你的部署鉤子來更新你的生產部署，並立即安裝新的庫版本。這將使得你的應用程式總是使用較新的庫進行更新，並且不會落後於幾年的發行版。
如果出現任何錯誤，你仍然能夠從dependabot中恢復提交——如果你希望使用乙個mergify規則，你也可以自動化恢復提交。
題外話
對我來說，這就是依賴關係管理生命週期目前的狀態。雖然這對python非常適用，但它也可以應用於使用了類似模式的許多其他語言，比如node和npm。
英文原文：譯者：天天向上
檢視依賴樹 Python中的依賴關係處理
對許多人來說，依賴關係是一場噩夢。一些人甚至認為它們是技術債務。管理你的軟體的庫列表是一種可怕的體驗。自動更新依賴項?這聽起來像是在說胡話。首先，我們需要清楚地了解一些有關依賴關係的知識 依賴關係有兩種型別。donald stuff幾年前寫的關於這個主題的文章比我要寫的都好。簡單一點來說，它們是依賴...
UML中的依賴關係
uml中的五種關係和設計模式中的 實現.又重新聽了一遍uml中的關係.感覺又是收穫很大.uml中的關係有依賴,關聯 聚合,組合 泛化 也叫繼承 實現 現在乙個乙個的來實現 一 依賴 依賴關係圖 他的意思就是use a 用到的意思,兩個類的 中不體現 看 c 但是在 中不體現,怎麼反映他們之間的依賴關...
RDD中的依賴關係
1.有shuffle 2.父rdd的乙個分割槽會被子rdd的多個分割槽所依賴 父一對多 1.沒有shuffle 2.父rdd的乙個分割槽只會被子rdd的1個分割槽所依賴 一對一 窄依賴 spark可以對窄依賴進行優化 合併操作,形成pipeline 管道 同乙個管道中的各個操作可以由同乙個執行緒執行...