前天看到 iThome 這篇〈微軟續拆解Python擴充套件,釋出3款獨立新套件〉,才知道原來微軟正在把 VS Code「Python 擴充套件」中的一些功能陸續獨立拆分出來。

於是昨天花時間摸索了一下其中和 Python 後端開發息息相關的兩個擴充套件,畢竟無論是 Black 或 isort 都是我一定會用到的工具,我非常想知道新的整合方式能帶來哪些便利。

不過,這兩個擴充套件目前都只有「發行前版本」,可以想成「測試版」,如果不是很迫切,可以等正式版發行再安裝使用就可以了,就讓我先來探一探路!

以下是我的測試心得。


Black Formatter

套件連結

測試結果:繼續保留使用。

於〈再見了 pip!最佳 Python 套件管理器——Poetry 完全入門指南〉中曾提過,雖然目前工作上是使用 yapf formatter,但個人專案已一律改用 Black,所以自然很好奇:安裝使用 VS Code 套件版本的 Black 究竟有什麼好處?

好處

好處很明顯,那就是你只需要安裝「一個」Black Formatter 擴充套件,就能讓所有使用 Black 排版程式碼的專案共用,而不必在各專案的虛擬環境中另外安裝 Black,可以統一使用 VS Code 提供的那一個!

換句話說,本來我只要一開新的個人專案,初始化階段一定要先poetry add black,現在完全可以省略這個流程。

期待 Flake8 也能推出獨立的 VS Code 套件版本,類似 Pylance

畢竟無論工作還是個人專案,我全都使用 Flake8,而 linter 或 formatter 這類工具因為部署時用不到,非常適合各專案在開發時「共用」,如果能只裝一個就太爽啦!

壞處

有好幾個,我覺得還可以接受,不過第三點真的比較煩人:

  1. Black 的版本會與擴充套件版本綁定:畢竟這套件相當於幫你安裝了一個「全域的 Black」,你無法自行決定要安裝的 Black 版本,只能取決於擴充套件使用的版本——通常就是最新版。考慮到 linter、formatter 的版本基本上不太需要和專案環境綁定,用最新的即可,所以我覺得問題不大,只是少了一點彈性。
  2. 無法使用 CLI 指令來操作black:對此比較大的影響是,如果你想一次格式化整個專案的所有 Python 檔案,用 CLI 指令就很方便,但 VS Code 套件不能這麼用。所幸對新專案來說比較無此需求,所以我還 ok。
  3. 新的設定會和舊的設定同時存在,容易混淆:這可能就真的比較頭大,獨立 Black 套件在settings.json的設定名稱和原有的 Python 主擴充套件不同,使用上需要明辨兩者間的關係與適用順序,如果像我一樣在不同專案之間會分別使用 yapf 或 Black,就更加麻煩。

此外,VS Code 套件本質上是為 Black 加上了一層封裝,多一層封裝就多一層複雜度,所以使用上可能存在一些難解的 bug 與環境設定衝突。

總之,建議可以等正式版上線再來使用,但我目前還是保留。

isort

套件連結

測試結果:暫時先刪除,但有額外收獲!

之前〈Flake8 與 isort in VS Code〉中提到「原來 isort 早就被 VS Code 內建」說法,後來發現其實不盡正確。嚴格來講它是被「Python 擴充套件」所內建,而現在正式被拆分出來。

「為 import 排序」說起來恐怕稱不上是硬需求,我覺得它對團隊開發而言,主要意義還是在於規範「協作上的一致性」,至於對個人開發的意義,我想是美觀吧!不過話說回來,對我這種規範控而言,自然是硬需求。

本來是衝著它帶有 linter 功能而去,也就是會提示你目前的 import 順序可能有誤。但我發現:排序 import bug 的暫時解法,在目前的新套件中沒有作用!導致排序依舊可能不正常,我也只能作罷!

然而並不是毫無收獲——在套件的介紹頁面中,我才知道透過settings.json設定,其實可以在存檔時就自動排序 imports,如此一來連 linter 提示都免了!讚啦!

1
2
3
4
5
6
7
"[python]": {
"editor.codeActionsOnSave": {
"source.organizeImports": true
},
...
},
...

小結

對於已經略顯肥大的 VS Code Python 擴充套件,微軟打算陸續將其功能拆分出來,我相信是正確的方向。

不過這段過渡期恐怕會有點辛苦,兩種設定可以並用,實在容易混淆。所以還是建議等到這些獨立套件的正式發行版上線,再來嘗鮮即可。