Python中的依賴關係處理

2021-09-28 20:18:35 字數 3139 閱讀 2802

對許多人來說,依賴關係是一場噩夢。一些人甚至認為它們是技術債務。管理你的軟體的庫列表是一種可怕的體驗。自動更新依賴項?-這聽起來像是在說胡話。

首先,我們需要清楚地了解一些有關依賴關係的知識: 依賴關係有兩種型別。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 管道 同乙個管道中的各個操作可以由同乙個執行緒執行...