Issue 131 We’ve updated our Privacy Policy  June 11th 2018

Inside the Cheeseshop: How Python Packaging Works

PyCon 2018 已經把所有議程的錄影放出來了，裡面有很多好料，大家記得去淘啊。不知道 PyCon Taiwan 什麼時候也能有這種效率⋯⋯不過小本經營就麻煩大家擔當點了，總之盡快。或者你明年說服你公司多拿點錢出來我們就能快一點。

總之我想特別推薦這個 talk，由新 PyPI pypi.org 維護者 Dustin Ingram 簡述 Python 套件管理究竟是怎麼走到現在，以及之後要怎麼繼續。雖然我以前也有講過類似的主題，不過像 The Vaults of Parnassus 我還是第一次聽到⋯⋯我在 Python 界還是很菜，這種歷史有沒有親身經歷還是有差。

我覺得貫穿整個演講的 theme 很棒：Python 套件管理的每個部分，都是為了解決某個問題而被創造，但也各自帶來新的問題。常常會聽到「為什麼 Python 套件管理會⋯⋯」與「為什麼你們又要開發新東西」的疑問，但這兩個問題不僅互為因果，又由於 Python 的各種歷史因素互相嵌套而非常難講清楚。我以後大概很長時間會 reference 這個 talk 來解釋。它對於 pip vs Conda、Pipfile(.lock)、pyproject.toml 的解釋也是我聽過最清楚的。三個不同的問題彼此相關，卻又需要獨立的解決方案，所以有三個不同解法同時在進行。如果你有過「為什麼有了 Pipfile 又需要 pyproject.toml」之類的疑問，這應該能澄清一些疑惑。

另外，如同最後一部分所述，Python 套件管理生態系真的完全、完全是由志願者在支撐。我前幾天剛好有說到（因為 PSF 董事會剛好改選），PSF 不負責進行 Python 的任何開發，所有 Python 開發也是完全志願性質，或者拿其他商業公司薪水。如果你有能力，就請考慮發個 pull request，主動參與開發吧。因為真的你不貢獻就沒有人了。

Pipenv 到底解決了什麼問題？

很多人在討論 Pipenv 的時候也會落入一個誤區，就是並沒有很理解它的所有部份，就根據自己看到的表象進行評價。這可能也是它一開始設計的決定，雖然不是錯誤，但是揉合了太多還不是普遍知識的元件導致。剛好我前幾天也講到這個主題，就一起放上來。希望這樣有釐清一些 Pipenv 定位的問題。

因為這個回應已經太長，我並沒有直接在裡面解釋「為什麼 Pipenv 的 locking 步驟這麼慢」。這有兩個原因。其中一個我有暗示，是因為它做了 pip 沒有做的事情（理論解析依賴視圖），如果你先看了第一個影片，可能猜得到另外一個：PyPI 其實根本不知道套件的依賴關係，所以 Pipenv 在解析時，必須把整個套件抓下來解析一次。如果你依賴的套件本身就很大（例如 Numpy 之類的），編譯時間很長，就會把解析步驟拖得非常、非常久。這是 setup.py 帶來的原罪，在淘汰它之前無法根治（不過我在引文裡有提到，還有一些改善空間啦）。

另外發問人在後來補充了他對 Python 套件目錄與 node_modules 設計差異的感想。確實如他所說，Python 的套件目錄無法處理依賴版本衝突的問題，所以 npm 的設計雖然常常讓人詬病，還是有其優點——我沒有查證，不過或許它本來就是針對這個問題所設計。但是它造成的後果還是太可怕，不值得為了虛無縹緲的假設問題犧牲，所以還是很多人在試圖改良它，而既然 Python 還沒踏入這個棺材，或許也還有另闢蹊徑的機會。Russ Cox 最近為 Go 提出的作法也十分有趣。

10 Things I Regret About Node.js

說到 npm——Ryan Dahl（Node 的初始作者）最近的講題整個很爆炸。Node 整個太爛所以我放棄了直接砍掉重練！當然 npm 也是他後悔的項目之一。不管它一開始想解決什麼問題，它的設計實在不夠好，尤其搭配 JavaScript 的「極簡風」標準函式庫，更讓問題顯得嚴重。

這個演講就純客觀角度而言，就是非常、非常中肯的批評，而這個批評的來源或許也能讓一些 Node fanboys 正視這個生態系的問題，好好自省一下。就我這個局外人而言，這也是個好好反省 Python 生態系有什麼需要轉換方向的部份；或許我們（還？）不需要把所有東西砍掉重練，不過至少需要不斷前進，甚至得思考怎麼改革一些很根深蒂固的問題（例如那個 G 開頭不能說的名詞），才能不被淘汰。