conda最佳實踐

為什麼使用conda而不是pip?

如果你是搞科學的就會知道，打包是一個多語言問題。你可以使用基於系統的非python庫安裝，但是如果你想要處理依賴於這些工具的多個版本的多個項目，那麼通常就會遇到一些問題。此時Conda就幾乎成了唯一的出路。況且，Anaconda還有針對Intel MKL(數學內核庫)編譯的包。這同樣也會使性能變得更快。

pip構造更慢一些

停止使用根環境

當人們開始使用conda/anaconda時，他們傾向於使用根環境(安裝程序創建的環境)來做所有的事情。接著，他們開始在裡面安裝很多東西，直到根環境崩潰，最終束手無策。

根環境崩潰時的我

相比之下，為每個項目創建獨立環境要容易得多。如果你搞砸了，你可以很方便地刪除它們，然後重新開始。根環境是用來安裝conda的地方。說真的，你的根環境應該只用於升級conda。其他所有事情都交給其他環境來做，這樣你的編程生活才會更加長久的幸福。

開始使用Conda構造器

如果你想要為一組用戶管理anaconda環境，構造器會是一個很好的工具! 在OSX/Linux/Windows上用於安裝Anaconda和miniconda的安裝程序是使用構造器構建的。構造器允許使用不同的規範來構建自己的安裝程序，因此你不再需要依賴anconda安裝程序，並且你可以根據團隊所需的數據科學環境來構建安裝程序。

使用構造器創建的安裝程序是部署生產應用程序的一種很不錯的方式。安裝文件往往比較大(因為所有二進位文件都被打包到可執行文件中)，但好處是安裝時不需要依賴網路。

Conda構造器不能在noarch包上工作——這可能會造成一些不便。(noarch包是一組獨立於平台的包——代表著你為linux/osx和windows構建了一個包)。其實有很多庫(比如django)看似是獨立於平台的，但實際上依賴於一些平台特定的包。

不要過分依賴於修改環境

通常情況下，構建環境並丟棄它們比無止境地修改要好的多。個中緣由是一個環境最終會進入一種奇怪的狀態。我知道這聽起來很糟糕——發生這種情況的主要原因是，隨著時間的推移，你會不停地升級conda，但它很可能會與舊的環境不兼容。另外，隨著時間的推移，你還會不停地修改環境，而環境通常又會繼續成長，這使得conda最終變得不可理喻(而且運行更慢)。

小心使用NFS

系統管理員和devops通常會為多用戶安裝集中的conda環境。這些環境會有一些緩存包作支持，而這些緩存包一般會存在於這個世界上一個可讀但不可寫的位置。當用戶創建自己的conda環境時，最終會在自己的主目錄中下載自己的包(這是通常情況，因為他們沒有許可權寫入到系統管理的緩存包中)。Conda可以從多個緩存包中對包進行符號鏈接，這當然很好。但是如果主目錄掛載了NFS後，當用戶試圖在多台機器上使用自己的環境，而這些機器並沒有相同的緩存包時，問題就會隨之產生。

在機器A上，我在/opt/anaconda下有一個集中安裝的anaconda。它包含 zeromq=4.2.5=hf484d3e_1。所以當我在~/.conda中創建自己的環境時，那個包就會被符號連接到我的環境中。但是，如果我嘗試在機器B上使用這個環境，其中緩存包不包含zeromq=4.2.5=hf484d3e_1，那麼我的環境就會崩潰。

你有幾個選擇

1、始終確保每台機器上集中的環境是相同的

2、在conda中禁止符號鏈接

我的建議是這兩者都要做。擁有相同的集中式環境這個主意相當好，這意味著無論用戶走到哪裡，他們都會得到相同的東西。此外，在共享環境中，禁用符號鏈接非常有用，因為如果你曾經升級過中心環境，那麼你最終可能會(通過刪除包)破壞用戶環境。

生產環境中不要太擔心conda激活器

Conda 激活器負責設置路徑和一些環境變數，這些環境變數會告訴Conda應該將內容安裝到哪個環境中。在部署應用程序時，這肯定會分散你的注意力。當部署應用程序時，在你的啟動腳本中引用二進位文件的絕對路徑要比調用激活器要容易得多。編輯:通常這是正確的，但是我聽說有些包(pyspark/rpy2)依賴於這個路徑。

在部署生產環境時，永遠不要試圖解析依賴關係

你可以編寫一個依賴於scikit-learn的應用程序，可以為應用程序構建一個conda清單，以便將其部署到生產環境中。這不是你的第一次上戰場，你做出了明智的選擇，然後一切就開始了，你設置

到你的清單中。非常棒！ 但是請注意，scikit-learn還依賴於

而且無需指明它依賴於哪個版本。如果你使用scipy 1.1.0進行測試，然後當你要部署scipy 1.2.0時，conda solver將會自動使用最新的版本，這樣你的生產環境就是1.2.0版本，這樣還省卻了程序的兼容性測試。

如果要確保所有嵌套的依賴關係都在生產之前完全解決。有兩種方法可以做到這一點。一種是使用conda env export來精確導出每一個想要部署的包的規範(精確到構建號)。這一切的動作必須發生在與生產環境部署相同的平台上。另一種方法是使用構造器。構造器好就好在安裝用構造器構建的東西時，不需要再對conda存儲庫有依賴。唯一的缺點是，由於所有東西都被塞到構造器安裝程序中，所以你要部署的文件大小通常至少是幾百兆位元組，可能是幾千兆位元組。

如果我需要的包不在Anaconda里呢

首先檢查Conda Forge。Conda Forge是一個用來構建所有東西的社區項目。有很大幾率你需要的包就在那裡，可以通過conda命令

指定conda-forge通道來安裝它。

如果失敗了——你可以使用conda skeleton從pypi包中生成一份conda清單。同時你還需要構建並上傳包到你自己的存儲庫中，因此這可能會很麻煩。

如果覺得構建自己的包太繁瑣，推薦使用pip。我這樣做是為了做探索性的工作。無論怎樣，我都建議你在發布到生產環境之前先構建適當的conda包。這樣做的原因是，對於不能完全依賴於pip的部署中，在進行部署(使用anaconda構造器或conda env導出)之前，確保你的依賴關係已經完全解決。

英文原文：https://www.opensourceanswers.com/blog/best-practices-with-conda.html
譯者：任宇は神様

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！