關鍵使用者體驗預期

1. 在系統、使用者或虛擬環境層級適當配置後，輕鬆讓外部託管「直接運作」。
2. 從使用者體驗中（無論是在安裝還是發布套件時），消除所有關於令人困惑的「可驗證的外部」和「不可驗證的外部」區別的提及。
3. PyPI 的儲存庫方面應該成為僅僅是預設的套件託管位置（也就是說，在大多數客戶端工具的預設配置中，它是唯一被視為「選擇退出」而非「選擇加入」的位置）。除了這一點之外，在 PyPI 上託管不應比託管自己的套件儲存庫提供更優越的使用者體驗。
4. 在執行上述所有操作的同時，提供預設的行為，使其能抵禦大多數國家級敵人以下的攻擊者。

為何需要額外的儲存庫？

兩種常見的安裝工具，pip 和 easy_install/setuptools，都支援額外位置的概念，以搜尋檔案來滿足安裝要求，並且已經這樣做了多年。這意味著無需「逐步引進」新的標誌或概念，從 PyPI 以外的儲存庫安裝專案的解決方案，無論終端使用者的安裝程式有多舊（在合理範圍內），都能運作。這個概念不僅在 Python 工具中存在了一段時間，而且它是一個跨語言的概念，甚至延伸到作業系統層級，作業系統的套件工具幾乎普遍使用多儲存庫支援，這使得人們極有可能已經熟悉這個概念。

此外，多儲存庫方法是一個在狹窄範圍之外也有用的概念，不僅限於允許希望被納入 PyPI 索引部分但不想利用 PyPI 儲存庫部分的專案。這包括公司可能希望託管包含其內部套件的儲存庫，或者專案可能希望擁有多個發布「通道」，例如 alpha、beta、發布候選和最終版本。這也可以用於希望託管無法上傳到 PyPI 的檔案的專案，例如數 GB 的資料檔案，或者目前至少是 Linux Wheels。

為何不採用 PEP 438 或類似方案？

儘管額外搜尋位置支援在 pip 和 setuptools 中已經存在相當長一段時間，但對 PEP 438 的支援僅從 pip 1.4 版本才開始存在，並且在 setuptools 中仍未實作。PEP 438 的設計確實意味著即使使用較舊的安裝程式，使用者也能從不需要外部檔案的專案中受益；然而，對於確實需要外部檔案的專案，使用者仍然默默地被提供潛在不可靠，甚至更糟的是，不安全的檔案供下載。這個系統也是 Python 獨有的，因為它源於 PyPI 的歷史，這意味著這個概念幾乎可以肯定對大多數（如果不是全部）使用者來說都是陌生的，直到他們在使用 Python 工具鏈時遇到它。

此外，PEP 438 提出的分類系統在實踐中被證明對終端使用者來說極為困惑，以至於本 PEP 認為現狀是完全站不住腳的。使用此系統的使用者常見模式是嘗試安裝專案，可能會收到錯誤訊息（或者如果專案曾經上傳過東西到 PyPI 但後來切換而沒有移除舊檔案，可能不會收到錯誤訊息），看到錯誤訊息建議使用 --allow-external，他們重新發出指令並添加該標誌，很可能又收到另一個錯誤訊息，這次錯誤訊息建議也添加 --allow-unverified，然後第三次發出指令，這次終於安裝了他們想要的東西。

這種使用者體驗失敗存在有幾個原因。

1. 如果 pip 可以在簡易 API 上為專案找到任何檔案，它將直接使用該檔案，而不是嘗試尋找更多檔案。這通常是正確的做法，因為嘗試尋找更多檔案會抹去 PEP 438 的大部分好處。這意味著如果一個專案曾經上傳過一個符合使用者安裝請求的檔案，無論該檔案有多舊，都將被使用。
2. PEP 438 有一個隱含的假設，即大多數專案要麼會自行上傳到 PyPI，要麼會更新自身以直接連結到發布檔案。儘管最終有大量專案決定上傳到 PyPI，但其中一些這樣做僅僅是因為 PEP 438 的使用者體驗太差，以至於他們感到被迫這樣做。然而，更令人擔憂的是，很少有專案選擇直接且安全地連結到檔案，相反，它們仍然只是連結到必須經過爬取才能找到實際檔案的頁面，因此使得安全選項 (--allow-external) 在很大程度上變得無用。
3. 即使作者希望直接連結到他們的檔案，安全地這樣做也並非顯而易見。它要求在 URL 的雜湊中包含 MD5 雜湊（出於歷史原因）。如果他們不包含此雜湊，則他們的檔案將被視為「未驗證」。
4. PEP 438 採取以安全為中心的觀點，不允許任何形式的未驗證專案的全局選擇加入。雖然這通常是件好事，但它會產生極其冗長和重複的指令調用，例如

   $ pip install --allow-external myproject --allow-unverified myproject myproject
   $ pip install --allow-all-external --allow-unverified myproject myproject
   

儲存庫端

1. 棄用並移除 PEP 438 所定義的託管模式。
2. 限制簡易 API 僅列出儲存庫中包含的檔案。

客戶端

1. 實作多儲存庫支援。
2. 實作某種移除/禁用預設儲存庫的機制。
3. 棄用/移除 PEP 438

我無法因 <X> 在 PyPI 上託管我的專案，我該怎麼辦？

首先您應該決定 <X> 是 PyPI 固有的問題，還是 PyPI 可以開發一個功能來為您解決 <X>。如果 PyPI 可以新增功能讓您在 PyPI 上託管您的專案，那麼您應該提出該功能。然而，如果 <X> 是 PyPI 固有的問題，例如希望維護對自己檔案的控制權，那麼您應該設定自己的套件儲存庫，並在您的專案描述中指示您的使用者將其添加到他們所選安裝程式將使用的儲存庫列表中。

我的使用者透過此 PEP 獲得比以往更差的體驗，我該如何解釋？

這部分答案會因每個專案而異，您需要向您的使用者解釋是什麼讓您決定在自己的儲存庫中託管，而不是使用他們安裝程式預設儲存庫列表中已有的儲存庫。然而，這部分答案也會解釋說，以前透明地包含外部連結的行為既是安全隱患（鑑於在大多數情況下，它允許中間人攻擊者在終端使用者機器上執行任意 Python 程式碼），也是可靠性問題，並且 PEP 438 試圖透過讓他們明確選擇加入來解決這個問題，但 PEP 438 也帶來了許多嚴重的可用性問題。PEP 470 代表著將模型簡化為許多使用者會熟悉的模型，這在 Linux 發行版中很常見。

轉換到儲存庫結構會破壞我的工作流程，或我的主機不允許這樣做？

有許多廉價或免費的主機，它們很樂意支援儲存庫所需的一切。特別是，您實際上不需要將檔案上傳到任何不同的地方，只要您可以生成一個具有正確結構的主機，指向您的檔案實際位置即可。這些主機中有許多使用共享域名提供免費 HTTPS，免費的 HTTPS 憑證可以從 StartSSL 獲得，或者在不久的將來從 LetsEncrypt 獲得，或者可以從許多提供商那裡廉價獲得。

你們為何不提供 <X>？

這裡的答案將取決於 <X> 是什麼，然而典型的答案通常是其中之一：

• 我們之前沒有考慮過，也沒有人提議過。
• 我們對 <X> 沒有足夠的經驗來為其妥善設計解決方案，並歡迎領域專家幫助我們提供。
• 我們是一個開源專案，目前還沒有人自願設計和實作 <X>。

額外提出新功能的 PEP 總是受到歡迎，然而它們需要有時間和專業知識的人才能準確設計 <X>。本 PEP 旨在讓我們達到一個目標，即 PyPI 的功能是直接且易於理解的基礎，類似於現有模型，例如 Linux 發行版儲存庫。

如果我反正都要運行自己的儲存庫，為何還要註冊 PyPI？

PyPI 為 Python 生態系統提供兩個關鍵功能。其中一個是作為中央儲存庫，用於儲存 pip 或其他套件管理器下載和安裝的實際檔案，而本 PEP 關注的正是此功能，如果您運行自己的儲存庫，您將取代此功能。然而，它也提供了一個中央註冊表，用於記錄誰擁有哪個名稱，以防止命名衝突，可以將其視為 Python 套件的 DNS。除了確保名稱以先到先得的方式分配之外，它還為使用者提供一個單一地點來搜尋和發現新專案。因此，簡單的答案是，您仍然應該在 PyPI 註冊您的專案，以避免命名衝突，並使人們仍然可以輕鬆發現您的專案。

允許更容易地發現外部託管索引

本 PEP 的先前版本包含一項新增功能，該功能已添加到 PyPI 和安裝程式中，允許專案作者在 PyPI 中輸入一個 URL 列表，該列表將指示安裝程式忽略上傳到 PyPI 的任何檔案，轉而返回一個錯誤，告知終端使用者這些額外的 URL，他們可以將其添加到其安裝程式中以使安裝正常運作。

此功能已從本 PEP 的範圍中移除，因為事實證明，開發一個能夠避免類似於 PEP 438 解決方案所導致許多問題的使用者體驗問題的解決方案過於困難。如果需要，未來的 PEP 可以重新審視這個想法。

維持現有分類系統但調整選項

本 PEP 拒絕了幾項相關提案，這些提案試圖修復現有系統的一些可用性問題，但同時仍保留 PEP 438 的核心思想。

這包括

• 預設允許安全地外部託管的檔案，但禁止不安全託管的檔案。
• 預設禁止安全地外部託管的檔案，僅提供一個全域標誌來啟用它們，但禁止不安全託管的檔案。
• 繼續遵循 PEP 438 建議的路徑，移除不安全外部託管的選項，但繼續允許安全外部託管的選項。

這些提案被拒絕，因為

• PEP 438 中引入的分類系統是 PyPI 獨有的概念，即使在 Python 套件的語境中也不具通用適用性。添加額外概念會帶來成本。
• 分類系統本身難以解釋，並且預先確定專案需要哪種類型的連結需要檢查專案的 /simple/<project>/ 頁面，以及可能從該頁面連結的任何 URL。
• 能夠在外部託管同時仍被連結以進行自動發現，這主要是一個歷史遺留問題，帶來相當多的麻煩和複雜性，卻收穫甚微。
• 安裝程式優化或清理使用者界面的能力受到限制，因為需要進行隱式連結爬取的性質。這不僅影響到 --allow-* 選項，也影響到無法判斷連結是否預期會失敗。
• 啟用選項時，此機制作用範圍非常廣泛，而 PEP 438 試圖透過每個套件的選項來限制這一點。然而，一個長期存在的專案通常會在其簡易索引中列出多個不同的 URL。其中至少有一個不再由專案控制的情況並不少見。雖然未註冊的域名在大多數情況下相對無害，但 pip 會在每個發現階段繼續嘗試從中安裝。這意味著攻擊者只需尋找依賴不安全外部 URL 的專案，並註冊過期域名來攻擊使用者。

實施此 PEP，但不要移除現有連結

這基本上是本 PEP 的向後兼容版本。它試圖讓使用舊客戶端或未實作本 PEP 的客戶端的使用者繼續運作，就像什麼都沒改變一樣。此提案被拒絕，因為這些情況中的絕大部分都是對已棄用功能的不安全使用。本 PEP 認為，默默地允許代表終端使用者執行不安全操作根本不是一個可接受的解決方案。