Pipenv投入使用後的回顧

如果你沒有在reddit上訂閱/r/Python頻道，那麼你可能不知道有關Python Packaging Authority、pipenv和poetry各自現今狀況的話題討論。pipenv和poetry的作者及PyPA的代表的參與使得這場討論變得更為有趣。如果你不介意在諸多無用的情緒化表達中尋找有趣的觀點，那就請便吧。

目前python的打包處理很糟糕，應該沒有人否認這一點。既然存在這個問題，那麼就有很多試圖解決這種混亂狀況的嘗試。Pipenv是第一個邁出這一步的，同時它也獲得了很大的進步，但它並不適合所有人。同時它也不適合所有項目——比如庫。

我使用Pipenv已經有一段時間了，我還試著將它引入到我們團隊的代碼庫中。自2017年11月左右開始，我們一直在使用Pipenv，2017年5月，我個人在GitHub上創建了我的第一個項目，以下是我的經驗：

在編號＃368的問題中我首先討論了多環境（例如測試了2.7和3.6）。我解決了我的項目中使用問題，但是＃1050仍然在討論這個問題。太長不看版如下：支持多環境與Pipenv的（因此也是Pipfile的）對不同應用環境可重用的理念背道而馳。所以如果你想對庫使用Pipfile，那你運氣不太好。這意味著許多項目不能使用Pipenv進行依賴管理。

細述的版本是關於Kenneth Reitz（Python社區中的令人驚奇的一部分，以及我的個人靈感）的過度直率和對社區需求不夠開放的態度。我建議徹讀1050號問題以便對此事形成自己的看法。雖然他的做法是可以理解的，但也可以理解為什麼有些人覺得Pipenv很糟糕。儘管我也討厭這樣，但實在沒辦法脫離評論作者來評論Pipenv，由於我會再次提到Kenneth，我先提前道歉。

不幸的是，我不止一次地經歷這樣的事：明明前一天還運行得很好的測試在第二天工作時報錯了。這一般都是Pipenv造成的問題。雖然該團隊幾乎總能快速解決問題，但如果我們因此遇到很大的bug並不得不部署修補程序，我們的品牌形象將會受損，而我們沒多少時間來定位問題所在，只能將Pipenv固定至以前的版本以希望它能正常工作。

如果這些是正確發布過程中的必經的錯誤，我不會太苛刻，然而事實是發布程序本身就有問題。因為根本沒有所謂的發布程序。Kenneth（這裡是第二次提到）經常會在主分支上連續修改並提交。我們也經常做這樣的事，連續進行十來次修改並提交或者恢復之前的更改。然而，我們並不是所有人都是在維護一個擁有將近11000顆星的GitHub項目，這還是一個每月170000次下載的項目，也是一個由python.org正式推薦的項目。我們都知道，依靠這一工具的人還是挺多的，而且很多人是不得不依靠的。

下一次出現這樣的另一個問題時，我只會將Pipenv固定在最後一個工作版本上，我應該從一開始就這樣做，直到我被迫更新。

• Pipfile和Pipfile.lock確實優於requirements.txt，很大程度上。

• 雖然我一開始不喜歡它，但在單個工具中內置flake8和安全檢查非常棒

• 從私人存儲庫（指定）安裝非常有效。在Pipfile中指定存儲庫而不是在系統中的某處替換一個dotfile文件很方便

• 創建一個新的Pipfile非常簡單

• 向Pipenv新用戶介紹很容易

• 安裝索引、git庫的混合體很容易...

• 通過--sequential，它實際上是確定性的，正如宣傳的那樣

• Virtualenv更容易理解

• 依賴可以安裝到系統中（例如在Docker中）——正如我們的案例

• 團隊中從未有人建議不用Pipenv——這一評價實際已經挺高的了

結論

Pipfile並不完美，我不知道它會不會逐漸完美，但我對它感到還算滿意，並且我將它推薦給其他團隊。但是，我不認為pipenv是最終目標。

作為一個社區我們需要一個適用於庫和應用程序的工具。 而這正是Pipenv特別不想成為的。Python社區最需要的是做出選擇（2還是3）。正如Python之禪所說：「應該有一個——而且最好只有一個——顯而易見的方法。」如果我們最終有多種工具用於多種目的，人們總會濫用所有這些工具的，無論如何，事情並不會很美好。

...Poetry呢？

我也希望我知道。自從我開始著手我們團隊現在的（GDPR相關）項目以來，我沒有太多時間再實驗了。但它看起來確實挺不錯的。

英文原文：https://ogmcsrgk5.qnssl.com/vcdn/1/優質文章長圖2/pipenv-review-after-using-in-production-a05e7176f3f0.png
譯者：β

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