プロフィール

髭山髭人(ひげひと)

自分の書いた記事が、一人でも誰かの役に立てば...
活動信条の一つとして「貴方のメモは、誰かのヒント」というのがあります。

このサイトについて

本家HP packetroom.net から切り離した いわゆる技術メモ用のブログで、無料レンタルサーバーにて運用しています。広告表示はその義務なのでご容赦。
XREA さんには長年お世話になっています

新環境に移行したら、VSCodeでPythonのデバッグが出来なくなってドツボに嵌った時のお話

経緯

起動用SSDを換装したので、OSのクリーンインストールなど含めて、作業用の環境を再構築(一新)しました。

もとより、Pythonの開発やら検証を Visual Studio Code(以下VSCodeと呼ぶ)で行っていたのですが、
新環境だとデバッグのF5ポチー押しても、うまくデバッグできない...どころか、ちゃんと実行もされてない?

っていうか前は表示されていたはずのターミナルにメッセージも出てこない?
そもそもターミナルに何も入力ができない!!

...等々、 明らかに前環境と違っていたので、これを何とかしようと奔走したときのお話です。
よく考えたら、今までずっと雰囲気でデバッグしてた ので、ちょっとした学ぶ機会?にもなりました。

自分は結構特殊な状況だと思うので「まったく同じ原因だった」という方は流石に早々いないと思うのですが、
また別の何かが原因で「VSCode上で(Pythonの)デバッグがうまくいかない」って人の手掛かりになればなーと。

先に結論

  • 作業用フォルダのPathが長すぎるとダメ
  • 起動するときにランチャーを噛ませていたのも間接的な原因
  • UAC(ユーザーアカウント制御)が絡んでいる可能性もある (未検証)

環境

  • Windows10 x64
  • Visual Studio Code
  • Microsoft謹製のPython用VSCode拡張機能を入れている (多分皆使ってそう)
  • Python 3.7.1 導入
  • pip も突っ込まれている
  • 自前のソースコード上で利用しているライブラリ(というかモジュール?)もインストール済み

調べてるうちに関係ありそうかな?と思ったいくつかの項目

ターミナルの起動タイプを変更する

まずターミナルにメッセージが出なかったのが気になったので、このあたりを調べていました。
どうやらWindowsだと、デバッグ・起動画面のターミナルは、コマンドプロンプトとPowerShellの2つが使えるらしいです

Ctrl + Shift + P 同時押しで出せるコマンドパレットから、たどれる以下の項目を弄る

Terminal: select default shell (既定のシェルの選択)
    ├Command Prompt
    └Powershell

↑「このへん弄ったら直らないかなぁ」と、シェルを変更してみるも、特に改善されず。

launch.json を書き換える

平時、F5等でデバッグ・実行するときに用いられる設定は、VSCode左側のデバッグ画面にある「デバッグ」一覧の中から、選択されている項目が適用されます。

状況に応じて選べるこれら複数のデバッグ設定は、ソースコードを突っ込んでいる同プロジェクト作業フォルダと同じ位置に大抵生成される .vscode フォルダ内の launch.json を参照しているようです。

IDE(統合開発環境)で良く勝手に作られる、あのファイルやフォルダと言えば多分伝わる人も多いんじゃないかなと思います。

launch.json は、デバッグ画面上部にある歯車マークから開いて編集するのがセオリーっぽいです。
そうするとVSCode上で開いて編集できます。
しかも編集中、右下に出てくる構成の追加ボタンを押すと スニペット的なアレな何かは分かりませんが、テンプレ的な設定を瞬時に追記してくれます。 わぁ便利!

ちなみに、この launch.json 初回プロジェクト追加時にはファイルとして存在しませんが、
歯車マークをクリックすることで、そのプロジェクト用デバッグ設定を保持するために新しく生成されます。
既に生成されている場合、二回目以降の歯車クリックは編集扱いとなります。

調べていくと、この各種デバッグ設定内の "console": に相当する所が原因なのかな?と思い、アレコレ弄ってみたものの結局改善されませんでした。

↓こんなやつ (launch.json 一部抜粋)

{
    "name": "Python: Current File (Integrated Terminal)",
    "type": "python",
    "request": "launch",
    "program": "${file}",
    "console": "integratedTerminal" //←このへんとか~?
}

今回の件、自分はこの項目が原因ではありませんでしたが、この辺ちょろっと覗き見するだけでも
「ふーんデバッグの設定ってここで弄るんだ~へぇ~」って完全に理解した気になれる (←わかってない) ので、関連しそうなリンクを一応張っておきます

日本語訳版:Visual Studio Code 日本語訳(非公式) > デバッグ > 起動構成
英文公式版:Visual Studio Code > デバッグ > 起動構成 ※2つとも内容は同じです

Pythonインタープリタを変更する

「オメェの使うインタープリタ(なにそれ)を選んでくれな!」ってオプションもあるようです

Ctrl + Shift + P 同時押し で、コマンドパレットから python select interpreter と検索。

出てくる項目を弄る事で、 「VSCodeでPythonを実行・デバッグする時に、何処に放り込むか」
というのが選べる模様?

多分個人の環境構築具合によると思うんですが、人によって

  • Anaconda X.X.X
  • Python X.X.X. -xxbit

みたいに、ちょっと分かれたりするかもしれません?

自分はPython 1つだけだったので、こちらも直接の関係はなさそうでした

VSCodeの設定ファイルと思わしきものを根こそぎ削除してみる

試行錯誤中に、Python本体やVSCodeをインストールしなおしたりしていたのですが、
VSCodeをアンインストール → PC再起動 しても消えていなかった2つのフォルダを見かけたので、根こそぎ削除してみました。
(※人によっては消えたら困る設定とかあるかもしれません、やる場合は自己責任で...!)

C:\Users\[ユーザー名]\ 以下に配置されている

  • .pyなんとか
  • .vscode

のフォルダ2つを削除。

→ 改善はされず(´・ω・`)

事態は急展開

こいつ..動いたぞ!?

なんとなく、VSCode再インストール後に作られたデスクトップのショートカットから普通に立ち上げてみました

...あっ、ターミナルがログを吐いた!!

ま さ か の

なんと、実は普段ランチャーアプリ経由でVSCodeを起動させていたのです。

いやいや、でも前環境では同じようにランチャーアプリ使ってましたが、こんなこと無かったんですよ。
「えっ前環境までは普通に起動 → デバッグ出来ていたのになんで」 となりましたが、 少し考えて ある事に気づきました…

UAC権限と起動位置の違い

実はOSのクリーンインストール・新環境を構築する際に、ランチャーアプリの位置を見直して変更させていました。

更に、自分自身のWindowsユーザーの権限も前とは微妙に異なっていました。
前環境では色々なソフトを起動するときに権限の許可を尋ねられるのがうっとおしかった為、
UAC(ユーザーアカウント制御)を「通知しない」に弄っていたのです。
逆に言えば、今回の新環境だとUACはデフォルトのままで弄っていません。

加えて、前環境のランチャーアプリは C:\Program Files\ という「如何にも」な場所に配置していましたが、
今回は D:\ドライブ内、任意の場所においてあり、そこから起動させていました。

試しにランチャーアプリを C:\Program Files\ 以下に配置し、
そこからまずランチャーを立ち上げ、更にそのランチャーから普段通りにVSCodeを起動...

あっターミナルがログ吐いてる...起動してる...(TヮT

UACでの是非は確認していませんでしたが、とりあえずランチャーアプリの位置を C:\Program Files\ に戻したら解決しました...orz

..と思ったら (二重の罠)

今度はブレークポイントで停止されない

VSCode起動時にターミナルが正常に起動できていた様なので、これで解決一安心!と思っていたら、
実際にブレークポイントを張ってF5デバッグを行うと停止されない!!なんで!!!

...と、これはググることで比較的速やかに解決しました。

デジタル・デザイン・ラボラトリーな日々 - Visual Studio CodeをPythonの開発環境として使ってみる
記事中にある「デバッグでブレークポイントが止まらない 」
で述べている箇所が参考になりました。

どうやらプロジェクトファイル群の位置(path)が長すぎるのが原因だったようです。
確かに現環境では、やや深めの所にPythonで書いたコード類を配置していました。

ちなみに実際に置いていた場所は以下の通り。 C:\Users\higehito\AppData\Local\Programs\Python\Python37\python_login

これを短くして
C:\MyProjects\python_login
のような浅めの場所に置いたら、無事ブレークポイントで止まってくれました。

ついでにF5実行時にターミナル(PowerShell)で吐いてたログも載せておきます

新環境 / ブレークポイントで止まらなかった長い(深い)ほう

// 見やすいように改行させています( 本当は一行 )
PS C:\Users\higehito\AppData\Local\Programs\Python\Python37\python_login>
cd 'c:\Users\higehito\AppData\Local\Programs\Python\Python37\python_login';
${env:PYTHONIOENCODING}='UTF-8'; ${env:PYTHONUNBUFFERED}='1';
& 'python' 'c:\Users\higehito\.vscode\extensions\ms-python.python-2018.11.  0\pythonFiles\experimental\ptvsd_launcher.py'
'--default' '--client' '--host' 'localhost' '--port' '50079'
'c:\Users\higehito\AppData\Local\Programs\Python\Python37\python_login\imcg_test_class.py'

新環境 / ブレークポイントで止まった短い(浅い)ほう

// 見やすいように改行させています( 本当は一行 )
PS C:\MyProjects\python_login> 
cd 'c:\MyProjects\python_login';
${env:PYTHONIOENCODING}='UTF-8'; ${env:PYTHONUNBUFFERED}='1';
& 'python' 'c:\Users\higehito\.vscode\extensions\ms-python.python-2018.11.  0\pythonFiles\experimental\ptvsd_launcher.py'
'--default' '--client' '--host' 'localhost' '--port' '50040' 
'c:\MyProjects\python_login\imcg_test_class.py'

根本的な原因の割り出しには至っていない

なんかもう途中で面倒くさくなって
「ランチャーの起動位置変更と、プロジェクトフォルダの階層変更で解決したからええわ」
ってなったんですが、 一応 他にも気になってるけど未検証な所を書いていきます

そもそも前環境では、あの長いPath位置で動いてた気がする

前環境と同じ位置に置いてた筈なんですけどねー
どうして新環境は長いPathだとダメだったんだろう。

disable path length limit の実行

Pythonインストール時に、 「python disable path length limit
という項目を実行するかどうかが出てきて訊かれたんですよね。
どのような効果なのかは、↑ のリンク先を漁るとわかると思うのですが、

  • 元々、Windows のファイルパスの長さは最大260文字まで制限されている
  • Pythonのインストールがてら、最後にここでこの制限撤廃オプションを選べる

との事。

新環境でもコレを実行したはず..なんですが、今回の事象とは直接は関係ない項目なのでしょうか。
なにぶん今回の原因の一つが「Path長すぎ問題」だったので、ちょっと気になります。

UAC(ユーザーアカウント制御) 云々

これも面倒で検証してないんですが、今この記事を書いているときも Windows10での UAC設定 をデフォルトのままにしています。

実のところ、この権限を弄って「通知しない」とかにしたら またちょっと都合が変わるのかなー?と思っています

最後に

根本的な原因の割り出しには至っていませんが、とりあえず

  • 起動で咬ませていたランチャーアプリの配置場所をC:\Program Files以下に変更
  • プロジェクトファイルの階層を浅くする

という感じで、なんとか二重の罠を潜り抜けることができました。

いやほんともう精神ごりごり削られました (TヮT
趣味でプログラミングやっているとはいえ、環境構築の手順はしっかり控えておいたほうが良いですね orz

UAC関係とかの検証は...精神的余裕ができたらまたやってみます..