microsoft / microsoft/vscode-python-environments
Poetry package listing fails for nested/non-root pyproject.toml projects (`poetry show` runs with wrong cwd)
まだ誰も着手していません。
- 主要言語
- 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
- Monorepo with
pyproject.tomlonly in a subfolder, e.g.scripts/pyproject.toml. - Add to
.vscode/settings.json:"python-envs.pythonProjects": [ { "path": "scripts", "envManager": "ms-python.python:poetry", "packageManager": "ms-python.python:poetry" } ] - Open "Manage Packages" for the
scriptsproject'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 withenvironment, e.g. viaapi.getPythonProject(environment.environmentPath)or similar) intoPoetryShowTopLevelCommandingetDirectPackageNames(). - 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 byenvId.idequality across all projects.
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- 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