Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

api to retrieve debugpy endpoint and access token?

オープン
  • 何か問題がありますか？
#1,529 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
python
領域
devtools

調査の方向性

まず、issue に示されている subprocess.Popen のシナリオと debugpy.connect の使用方法を確認し、次に debugpy がサブプロセスの追跡と接続の詳細をどのように処理しているかを追跡します。要求されている公開エンドポイントおよび access-token API を、VS Code/debugpy について説明されている既存の動作と比較します。サポートされるサブプロセスのアプローチまたは API 要件が明確に判断され、外部プロセスのユースケースにも対応できれば完了です。

索引モデルが issue の本文から書いたものです。

説明

I have a program which launches python subprocesses via python's subprocess module using an invocation syntax like:

subprocess.Popen("./path/to/script/with/pyshebangscript", ...])

Where pyshebangscript looks like this and is an auto-generated shim created by poetry from the [tool.poetry.scripts] pyproject.toml section.

#!/app/pypoetry/virtualenvs/appname--PefSXhl-py3.10/bin/python
import sys
from zephyrus.cli import app

if __name__ == '__main__':
    sys.exit(app())

AFAICT this mechanism for invoking the sub process defeats the default subProcess: true tracking behavior in debugpy.

I found a workaround which appears to work wherein I explicitly reconnect the subprocess back to the original debugging session (here I'm assuming that os.environ is exported from parent to child process so that the env variables updated below propogate information to the subprocess).

I put this code in my project's root most __init__.py file

import os

DEBUGPY_ENDPOINT = os.environ.get("DEBUGPY_ENDPOINT", None)
USE_DEBUGPY = os.environ.get("USE_DEBUGPY", None)

if USE_DEBUGPY is not None and DEBUGPY_ENDPOINT is not None:
    import debugpy

    debugger_host, debugger_port = os.environ["DEBUGPY_ENDPOINT"].split(":")
    print(f"Connecting to debugpy host process on {debugger_host}:{debugger_port}")
    debugpy.connect(
        (debugger_host, int(debugger_port)), access_token=os.environ["DEBUGPY_TOKEN"]
    )
    debugpy.wait_for_client()
    print("Connected to debugger process")

if USE_DEBUGPY is not None and DEBUGPY_ENDPOINT is None:
    import debugpy

    def get_debugger_endpoint():
        import os
        import psutil

        parent_pid = os.getppid()  # Get parent process ID
        parent = psutil.Process(parent_pid)

        parent_cli = parent.cmdline()
        debugpy_endpoint = parent_cli[3]
        debugpy_token = parent_cli[7]

        return debugpy_endpoint, debugpy_token

    debugger_endpoint = get_debugger_endpoint()
    os.environ["DEBUGPY_ENDPOINT"], os.environ["DEBUGPY_TOKEN"] = debugger_endpoint
    print(f"Debugger endpoint found at {debugger_endpoint}")

The above snippet includes some hacky logic to detect the debugpy endpoint and access_token from the original process's parent process's cli arguments ...

So with that context - I suppose I have a two part question here.

FIrst -- is there a good way to change the subprocess.Popen invocation that wouldn't defeat the built in subprocess tracking logic in vscode/debugpy?

Second -- if I do need to do something like above to get this working properly, would it be possible to add something to the public api of debugpy to make it easy to directly observe the endpoint and access token associated with a connected process? Retrieving these values is needed so that these values can be passed along from the originally debugged process to the subprocess(es) it launches -- where those subprocesses will in turn debugpy.connect() back to the active debugging session.

I think a mechanism to observe these values would be useful even if there's a better way to handle this exact problem, as I believe the logic above would work for subprocesses that get launched on remote hosts as well. I do this on my system as these subprocesses may also execute inside of cloud run jobs ... To get the experience I want (pausing on breakpoints on code executing a cloud run job) -- I think all I will need to figure out is how to get vscode's debugpy debugger type to support connections from external network's (rather than binding the debug server port to the default 127.0.0.1 only).

主要言語
Python
スター
2.5k
フォーク
202
平均マージ
1日 20時間
マージ済み PR（30日）
3

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

microsoft/debugpy のほかの issue

microsoft/debugpy の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。