Python: 搶救 Python 大兵 (如何擺脫 anaconda 的糾纏)－傑克! 真是太神奇了!

前言

前幾天 (寫完其實已經過了一個多月了), 在 Windows10 上, 遇到了一個非常機車的問題: Python for Window 的執行檔 python.exe 被 Anaconda 版的 python.exe 綁架了.

狀況是這樣的, 最近去上了大數據/AI的課, 上課時教 python 的老師用的是 Anaconda 所提供的 Jupyter Notebook 環境, 所以同學的電腦上安裝的都是了 Anaconda 個人版 (Individual Edition) for Windows. 而我個人則是標新立異愛作怪, 用 Python 內建的虛擬環境, 再加裝上 jupyterlab 相關的 package, 還有其他上課所需的 package 來應付上課時的需求. (其實是因為上課之前試用過 Anaconda, 覺得它真的太肥了, 而且 Anaconda 整體反應有點 lag. 所以決定改用 python 內建的虛擬環境的功能內建置 jupyterlab 環境...)

其實, 說起來 Anaconda 對於一個 python 初學者同時又對電腦運作不甚了解的人來說, 算是一個不錯的選擇. 它以容易上手的圖形環境展現給一般使用者, 同時又預設好 jupyter notebook 網頁, 讓初學者可以只專注在學習 python 上. 可惜的是, 它的圖形系統有點厚重. 和它在 CLI 環境的輕便好用完全是二回事. 好了, 廢話不多說, 來看看到底發生什麼事?

再後來發現 VS Code 竟然可以直接開 Jupyter Notebook 的 .ipynb 檔, 呈現出和 Jupyter Notebook 網頁一樣的畫面, 而且除了和 Jupyter Notebook 一樣的進行編輯和執行 python code, 還有變數表可以查看內容, 同時又可以單行執行, 簡直是初學者的天堂啊!! 所以就在班上大力的推廣. 接下來, 慘案就發生了...

症狀

有人的電腦新建的 Python 虛擬環境無法更新 pip, 出現 SSL/TLS 錯誤_(註一); 但有些人則時可以.
python.exe 竟然是 Anaconda 內附的 3.8.3 版 (不論是 VS Code 裡, 還是 windows command console), 而不是新安裝的 Python for Windows (python.org 3.8.6 版本).
後來還發生在虛擬環境裡加裝的 python 套件憑空消失, 找不到套件無法 import.

註一: 狀況有點類似 pip #5448 這個 issue.

解決過程

由於想讓不熟 windows 系統的同學可以繼續使用原先的 Anaconda, 我教同學以系統安裝加裝一個 python for windows 環境. 然後, 建虛擬環境時是用 py -m venv 環境名字 讓 python launcher 自行挑選 Windows 裡安裝的最新版的 python. 但是不知為何 py.exe 就是一直使用版次較低的 3.8.3 版. 試了好幾個比較有可能的嫌疑犯和解決方法但都還是無法解決. 例如:

關閉微軟的 "應用程式執行別名" 裡的 python.exe, python3.exe
增加新安裝的 python 路徑到環境變數 PATH裡.
還有試著加上 py.ini 檔_(註二)
...

也還是無法從 anaconda 手中救出人質. 最後在 python 的手冊上讀到有個環境變數 PYLAUNCH_DEBUG 可以設定_(註三), 想說死馬當活馬醫, 看看到底 debug mode 會不會出現什麼有用的資訊可以協助解決這個問題. 這才發現: 原來 py.exe 也有找到新裝的 3.8.6 版的 python, 但是 py.exe 說 HKCU 的優先權比較高!!??_(註四)

使用 regedit 找尋 python 相關的 registry, 發現 Anaconda 的版本是出現在 HKCU\SOFTWARE\Python\PythonCore\3.8\InstallPath, 而新安裝的 3.8.6 版則是出現在 HKLM\SOFTWARE\Python\PythonCore\3.8\InstallPath.

即然 py.exe 選擇 Anaconda 那一份, 那就把它刪掉吧?! (或者換成 python for windows 那一份也可以) 果然 py.exe 的問題解決了. (所以在 Windows Command Console 以 py.exe 呼叫 python OK 了, 新建 Python 虛擬環境 也 OK 了.)

註二: 檔案 py.ini 可以放置的路徑有二 %windir%, %LOCALAPPDATA%. 內容範本如下:

[defaults]
python=3.8

註三: python 3.11.x 已經將環境變數 PYLAUNCH_DEBUG 更名為 PYLAUNCHER_DEBUG.

註四: HKCU, HKLM 是 Windows registry 內的二個次高層的註冊進入點 (直接放在進入點電腦下).
HKCU: HKEY_CURRENT_USER.
HKLM: HKEY_LOCAL_MACHINE.

py.exe 的問題解決了, 但是部份人的 VS Code 裡還有問題, 幾經在 .ipynb 檔中使用 !python -V, !where python 測試並查驗. 發現也需要把 Anaconda 從環境變數 PATH 中移除, 並設定正確的 python interpreter (我們自己開設的虛擬環境裡的那一個) 才完全不受 Anaconda 影響.

至此大多數人的環境都 OK 了, 但還是有一位同學的 VS Code 環境竟然還一直被 Anaconda 刼持著, 甩不開. 後來查到他誤裝了 Anaconda Extension Pack, 但關閉功能及解安裝都沒有辦法免除 Anaconda 的影響 (甚至重開機, 重新安裝 VS Code 也都沒用...). 最後刪除 VS Code 的快取, 終於把問題給決解了... 真是打不死的小強啊!!

解決方法總結

安裝 Anaconda 時一定不要勾選把 Andconda 加到 環境變數 PATH 裡和將 Anaconda 內附的 python 註冊為預設的 python 執行檔.
如果已經這麼作了, 那麼請你:
- 刪除環境變數 PATH 中所有和 Anaconda 相關的路徑 (應該是有 5 個).
- 刪除 Anaconda 在 Windows registry 中的註冊: HKCU\SOFTWARE\Python\PythonCore 或 HKLM\SOFTWARE\Python\PythonCore.
不要安裝 Anaconda Extension Pack 這個 VS Code plugin (MS 已經將它從 MS Store 中 "下架" 了, 但是從 Google search 還是可以找到).
如果已經這麼作了, 那麼請你:
- 解安裝 Anaconda Extension Pack.
  不要只是關閉 (disable). 關閉解決不了問題, 只有解安裝並刪除了快取才有效.
- 清理 VS Code 的快取及一些系統設定:
  關閉 VS Code, 直接刪除 C:\Users\<使用者帳號>\AppData\Roaming\Code, 然後重開 VS Code.
如果你最後選擇移除了 Anaconda, 記得查一下以下的 Windows registry, 如果有請你把它刪除.
HKCU\Software\Microsoft\Command Processor

其他

問題根源之一

後來我在 Python 文件 PEP 514 讀到:

Tools that aim to select a single installed environment from all registered environments based on the Company-Tag pair, such as the py.exe launcher, should always select the environment registered in HKEY_CURRENT_USER when than the matching one in HKEY_LOCAL_MACHINE.

原來, py.exe 認定 HKCU 那一份的優先權比 HKLM 那一份高. 知道問題所在, 解決方法當然就是直接把 HKCU 那一份 registry 刪了. ~~或者再安全一點, 把 HKLM 的那一份也 copy 一份到 HKCU.~~

一直誤以 Windows 的系統安裝優先權要比用戶安裝來得高 (因為環境變數 PATH 就是系統的在前, 用戶的在後), 結果是大錯特錯. 只能說不經一事不長一智.

問題根源之二

之後, 我又在 VM 上重新檢視 Anaconda for Windows 的安裝過程. 發現其實 Anaconda 在安裝過程中, 有善意的提醒了不必把 Andconda 加到 環境變數 PATH 裡, 但是卻建議將 Anaconda 內附的 python 註冊為預設的 python 執行檔.