microsoft / microsoft/vscode-python-environments

Poetry package listing fails for nested/non-root pyproject.toml projects (`poetry show` runs with wrong cwd)

オープン
#1,779 コメント 1 件 リアクション 1 件 担当者 0 名 GitHub で見る

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

triage-needed
主要言語
TypeScript
スター
138
フォーク
62
平均マージ
1日 4時間
マージ済み PR(30日)
35

説明

Environment
  • vscode-python-envs version: 1.36.0
  • OS: Linux (devcontainer, linux-arm64)
  • Poetry: 2.4.3
Description

When a Poetry project is registered via python-envs.pythonProjects but is not at the workspace root (e.g. a monorepo with scripts/pyproject.toml), the "Manage Packages" package listing fails with:

poetry: Poetry could not find a pyproject.toml file in <extension host cwd> or its parents
Root cause (found in source)

PoetryPackageManager.getDirectPackageNames() (src/managers/poetry/poetryPackageManager.ts) builds PoetryShowTopLevelCommand without ever passing a cwd:

const showTopLevelCmd = new PoetryShowTopLevelCommand({
    pythonExecutable: poetry,
    log: this.log,
});

This means poetry show --no-ansi --top-level always inherits the extension host process's own cwd (in a remote/devcontainer setup this is the vscode-server install directory), not the project directory. This is confirmed intentional by the existing unit test poetryPackageManager.unit.test.ts: "direct package listing inherits the process working directory" asserts runPoetryStub.firstCall.args[1] === undefined.

fetchPackagesFromTool() (used for plain poetry show --no-ansi) does compute a cwd via getPoetryCwd(), but that logic only reliably resolves when api.getPythonProjects() returns exactly one project. Since VS Code always implicitly adds the workspace root as a project (PythonProjectManagerImpl.getInitialProjects()), any repo with a registered non-root Poetry project (e.g. scripts/) ends up with 2+ projects, forcing the "match by environment identity" branch — which can return an empty matchingDirectories set (and thus undefined cwd) depending on how the workspace-root's own resolved environment compares.

Repro
  1. Monorepo with pyproject.toml only in a subfolder, e.g. scripts/pyproject.toml.
  2. Add to .vscode/settings.json:
    "python-envs.pythonProjects": [
      { "path": "scripts", "envManager": "ms-python.python:poetry", "packageManager": "ms-python.python:poetry" }
    ]
    
  3. Open "Manage Packages" for the scripts project's Poetry environment.
Expected

poetry show commands run with cwd set to the registered project directory (scripts/).

Actual

Both poetry show --no-ansi --top-level and poetry show --no-ansi fail with "could not find a pyproject.toml", repeating every time packageWatchers triggers an auto-refresh.

Suggested fix
  • Pass cwd (resolved from the project associated with environment, e.g. via api.getPythonProject(environment.environmentPath) or similar) into PoetryShowTopLevelCommand in getDirectPackageNames().
  • In getPoetryCwd(), prefer resolving cwd from the actual project that owns the environment (e.g. via reverse lookup by environment path) rather than only matching by envId.id equality across all projects.

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

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

調査の方向性

src/managers/poetry/poetryPackageManager.ts、特に getDirectPackageNames() と getPoetryCwd() から始め、次に poetryPackageManager.unit.test.ts と、そこに既存するプロセスの作業ディレクトリに関するアサーションを確認します。ネストされたプロジェクトで、登録済みのプロジェクトと環境がどのように解決されるかを追跡します。両方の poetry show コマンドが登録済みプロジェクトのディレクトリを使用し、Unit Test がその cwd の動作をカバーすれば完了です。

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

評価

技術スタック
python, typescript
領域
developer-experience, tooling
issue の種類
バグ
難易度
4/5
見積もり時間
3〜5日
活発さ
活発
明瞭さ
明確に書かれている
初心者へのやさしさ
74/100

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

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